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DECISION SUPPORT SYSTEM FOR THE 
MANAGEMENT OF AN AGILE SUPPLY 
CHAIN 

CROSS-REFERENCES TO RELATED 
APPLICATIONS 
This application claims the benefit of U.S. Provisional 
Application Nos. 60/005,860, filed Oct. 26, 1995; 60/008. 
101. filed Oct. 30. 1996; 60/022,787, filed Jul. 30, 1996; and 
"60/012327, filed Feb. 27, 1996. 

BACKGROUND OF THE INVENTION 

1, Field of the Invention 

The present invention is directed to a system for support- 
ing management decisions associated with manufacturing of 
service supply chains that span from a point of creation to a 
point of consumption and, more particularly, is directed to a 
system that allows the various decision makers in the supply 
chain to view the supply chain from their own perspective, 
obtain information and evaluate decisions concerning past, 
current and future performance with respect to a diverse set 
of often conflicting goals. 

2, Description of the Related Art 

Many types of manufacturing database management and 
inventory control systems exist today. Each of these systems 
views the process from the narrow viewpoint of the goals of 
such a system. For example, inventory control processes 
tend to determine when the inventory of an item is projected 
to be depleted and when to order goods to prevent such 
depletion. The inventory control process does not generally 
take into account the problems associated with availabilhy 
of materials and machines to satisfy the inventory demand. 
On (he other hand the manufacturing control process con- 
siders the availability problem but does not take into account 
the effect of a sales promotion that will deplete an inventory 
faster than projected. A marketing department in preparing 
a sales promotion will often not consider the effect that 
promotion will have on availability, inventory and profit 
margin but tends to focus on sales goals. What is needed is 
a system that will support managers with each of these view 
points in understanding the effect of the various decisions 
that can be made on the supply chain as a whole both 
currently and into the near future. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a system 
that allows a decision maker in a supply chain to view the 
chain from their own perspective and understand the effect 
that their decisions will have on the supply chain as a whole. 

It is another object of the present invention to provide a 
distributed and layered architecture that allows the reuse of 
processing resources and data in making diverse different 
view point decisions concerning a supply chain. 

It is also an object of the present invention to provide a 
User Interface that projects a view (a Decision Support 
Frame) into the supply chain that takes into account the view 
point of the particular user, such as a plant manager or sales 
manager. 

It is another object of the present invention to provide 
quantitative models and analytical processes to support the 
plans prepared and decisions made from the various supply 
chain view points such that these resources are cost effec- 
tively provided and utilized in across the entire supply 
chain-wide. 

It is also an object of the present invention to provide a 
scenario management system in which Scenarios can be 
saved, modified and data transferred between view [Kiinls or 
frames. 
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It is a further object of the present invention to allow the 
user to specify a data domain that limits the data used for a 
particular view point. 

It is an additional object of the present invention to 
5 provide a system that will reconcile the demand and supply 
aspects of a supply chain. 

It is still another object of the present invention to allow 
the creation of an integrated production, sales and inventory 
(PS I) plan and provide a projection concerning what is 
feasible in the production, sales and inventory plan. 

It is an object of the present invention to allow the 
manufacturer or vendor to plan the supply of goods and 
services for a customer that integrates all information about 
a product, including current, past and projected future sates 
and inventory, into a feasible replenishment plan. 

It is a further object of the present invention to provide a 
planning process that reconciles top down and bottom up 
projections. 

2Q It is an object of the present invention to provide expert 
based models that allow forecasts from various view points 
including a bottom up view point. 

It is also an object of the present invention to operate in 
an interactive and dynamic decision environment, providing 

25 decision support to single or a set of users. 

It is also another object of the present invention to 
maintain overall data consistency and provide performance 
feedback to users reflccfing the impact of "local" decisions 
on global supply chain performance. 

•30 The above- identified objects can be attained by a decision 
support system for the management of agile supply chains 
that provides an architecture including a server side and a 
client side. The server side includes a decision support 
system database that interfaces with one or more model 

35 engines that perform analytical processes on the data to 
determine requirements and make projections. The server 
side includes a server manager thai coordinates requests for 
service and information. The client side includes Decision 
Support Frames that present the various view points avail- 

40 able in the system to the users. A frame manager that 
coordinates the requests from Decision Support Frame (view 
points) is provided by the system to access I he needed data 
and models. 

These together with ether objects and advantages which 
will be subsequently apparent, reside in the details of 
construction and operation as more fully hereinafter 
described and claimed, reference being had to the accom- 
panying drawings forming a part hereof, wherein like 
numerals refer to like parts throughout, 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 DSS System Architecture: in the Context of Manu- 
facturing Supply Chains. 

FIG. 2 DSS System Architecture in the Context of Equip- 
ment Repair Supply Chains. 

FIG. 3 Decision Support Thread. 

FIG. 4 ITie Data Spaces in Supply Chain Management. 

FIG. 5 Structural Elements in the DSS Database for the 
^ Manufacturing Supply Chain. 

FIG. 6 Structural Elements in the DSS Database for the 
Equipment Repair Supply Chain. 

FIG. 7 Specification of Decision Support Frame. 

FIG. 8 Decision Processes in the Manufacturing Supply 
65 Chain. 

FIG. 9 High Ijcvel Model of an Equipment Repair Supply 
Chain and the Decision Processes. 
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FIG. 10 Process and Data Flow Diagram Legeod. 

FIG. 11 Data Space Associations of the Demand Man- 
agement Frame. 

FIG. 12 Process Flow of the Demand Management 
Frame. 

HG. 13 Process Flow of Order Fulfillment. 

FIG. 14 Data Flow for the Demand Management Frame. 

FIG. 15 Data Space Associations of the Production-Sales- 
Inventory Planning Frame. 

FIG. 16 ProcKSS Flow of the Production -Sales- Inventory 
Planning Frame. 

FIG. 17 Data Flow for the Production -Sales- Inventory 
Planning Frame. 

FIG. 18 Data Space Associations of the Supply Manage- 
ment Frame. 

FIG. 19 Process Flow of the Supply Management Frame. 

FIG- 20 Data Flow for the Supply Management Frame. 

FIG. 21 Data Flow for the Supply Management Frame. 

FIG. 22 Data Space Associations of the Vendor Managed 
Replenishment Frame. 

FIG. 23 Process Flow of the Vendor Managed Replen- 
ishment Frame. 

FIG. 24 Data Flow for the Vendor Managed Replenish- 
ment Frame. 

FIG. 25 Data Space Associations of the Distribution 
Network Design Frame. 

FIG. 26 Process Flow of the Distribution Network Design 
Frame. 

FIG. 27 Data Flow for the Distribution Network Design 
Frame. 

FIG. 28 Seven Modules and Supply Chain Management. 

FIG. 29 Paretc Analysis for ABC Classification. 

FIG. 30 Scatter Plot for Sales-Volatility Qassificalion. 

FIG. 31 Impact of Sales Promotion. 

FIG. 32 Curve Fitting for Promotion Effect Analysis. 

FIG. 33 System Level Services, the Seven Modules and 
Model Engine Utilities. 

FIG. 34 Supply Chain Frame Manager: High Level Archi- 
tecture. 

FIG. 35 High Level Architecture of the System Integrator. 

FIG. 36 High level object representation of the system 
integrator portion of the frame manager. 

FIG. 37 High Level Architecture of the Functional Inte- 
grator. 

RG. 38 Data How Diagram for the Supply Chain Net- 
work Configurator. 

RG. 39 Functionality in the Domain Manager. 

FIG. 40 Hierarchical Structure of a Scenario. 

FIG. 41 Data Flow Diagram for the Performance Simu- 
lator. 

FIG. 42 User-DSS Interaction Process. 
FIG. 43 Sample Screen from PSI DSS. 
no. 44 Three-tier Application Development Architec- 
ture. 

HG. 45 DSS Development Platform Environment. 
FIG. 46 Generic System Architecture. 
FIG. 47 System Architecture in View of the DSS Proto- 
type. 

FIG. 48 The l^ogon Dialog Box. 

FIG. 49 The Opening Screen of the DSS. 
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FIG. 50 User Preferences Selection Dialog Box. 
FIG. 51 The Select Data Domain Form. 
FIG. 52 Edit Data Domain Dialog box. 
J FIG. 53 Make Product Domain Dialog Box. 
FIG. 54 Save Scenario Dialog Box. 
FIG. 55 Open Scenario Dialog Box. 
FIG. 56 Demand Management, Bottom Up Forecast 
Screen. 

FIG. 57 Demand Management, Top Down Forecast 
Screen. 

FIG. 58 Promotion Calendar Main Display. 

FIG. 59 The Promotion Selection Wizard. 
j5 FIG. 60 The Main PSI Frame Form. 

FIG. 61 The Options menu choices on the PSI screen. 

FIG. 62 PSI Reconciliation Order Dialog Box. 

FIG. 63 The main capacity checking dialog box — The 
Options tab. 

FIG. 64 The Results tab. 

FIG. 65 The Production Resource tab. 

FIG. 66 The Key Components tab. 

FIG. 67 The Bill of Material tab. 
25 FIG. 68 The Alternative Components Tab. 

FIG. 69 The Resource Requirement tab. 

FIG. 70 Key Component Selection Dialog Box. 

DESCRIPTION OF THE PREFERRED 
30 EMBODIMENTS 
Introduction 

Overview of the DSS Conceptual 
Architecture 

The Decision Support System (DSS) 10 of the present 

35 invention (.see FIG. 1) relies on quantitative models and data 
analysis routines to provide decision support. Consider for 
example the production, sales and inventory (PSI) planning 
process. An architecture to provide such support in accor- 
dance with the present invention comprises a library of 

40 models and routines that are logically linked, regularly 
updated and maintained. To support the PSI planning pro- 
cess for example, one can then employ an appropriate subset 
of models and routines from the library to represent the 
underlying supply chain abstraction and provide decision 

45 support. The present invention assembles the models and 
routines in a flexible manner, as needed by a decision 
making environment, to enable the DSS 10 to provide 
customized decision support with a readily upgradable and 
scalable library. 

50 Principal Design Elements 

The architecture of the Decision Support System (DSS) 
10 for a manufacturing supply chain is shown in FIG. 1 and 
comprises the principal design elements of: a DSS Database 
12 with a Database Management System (DBMS) 14 and 

55 Supply Chain Information Systems 15, Decision Support 
Frames 16 which provides the various supply chain view 
points, a User Interface 18, a Model Engine 20 including 
various Model Engine Utilities (processes) 22 and a Supply 
Chain Frame Manager 24. The architecture of the DSS 10 in 

60 the context of an equipment repair supply chain is Illustrated 
in FIG. 2. 
Salient Features 

The DSS architecture comprises two basic mode divi- 
sions: the Client Mode 30 and the Server Mode 32. ITicse 

65 modes can be classified with respect to an Implementation of 
tlie DSS 10 in a supply chain. From a design standpoint (he 
Client Mode 30 is the portion of the DSS architecture that is 
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specific and therefore customizable to provide decision 
support for any panicular decision process and decision 
maker. The Server Mode 32, on the other hand, is the kernel 
of the DSS architecture that remains largely the same across 
different applications of the DSS 10 within a given supply 3 
chain. Hence, for a given implementation of the client-server 
DSS architecture in a supply chain, there will be one Server 
Mode 32 and a number of Client Modes to provide support 
for the decision processes. 

As shown in FIGS. I and 2 the Client Mode 30 comprises lo 
the User Interface 18, the Decision Support Frames 16, and 
the client version of the Supply Chain Frame Manager 24. 
The Server Mode 32 comprises the Supply Chain Frame 
Manager 24, the system level services, the Model Engine 20, 
and the DSS Database 12. The Supply Chain Frame Man- 15 
ager 24, as a participant in both modes, serves to tic the 
Client and the Server Modes of the architecture together. 

The client-server architecture makes the overall design 
both extensible (new functionality can be added by custom- 
izing a frame in the Client Mode 30) and scalable (new 20 
models and routines can be added to the Model Engine 20 
in the Server Mode 32). Additionally this design is network- 
able; one can visualize the Server Mode 32 of the DSS 10 
hosted by a server workstation in a client-server network 
while a number of Client Modes 30 of DSS 10 are hosted in 25 
the client computers. The layered design of the architecture, 
in terms of how the principal design elements of the DSS 10 
are positioned within the architecture, provides a more 
resilient and stable backbone for decision support. The high 



cations and descriptions in this document address the two 
distinctive supply chains previously mentioned: I. Manufac- 
turing; Finished goods arc produced from raw materials, 
components, and subassemblies using resources (e.g., 
humans and machines) distributed to the demand points, and 
consumed by the end users. Material flow can be character- 
ized as linear. II. Equipment Repair: Failed items arc sent to 
the repair facilities, repaired using resources (e.g., humans 
and test equipment), and restored to usable condition. Mate- 
rial flow can be characterized as re-entrant. 

Even though a typical manufacturing environment may 
perform a limited amount of repair operations, such as 
machine maintenance or product service, its resources are 
predominantly dedicated to material procurement, finished 
goods production and distribution. In this view, the distin- 
guishing characteristic between the manufacturing and 
repair environments is the degree to which the environment 
focuses on the production of new goods versus the repair of 
old ones. Compared to the manufacturing supply chain, the 
equipment repair supply chain has complex reentrant flows, 
while the manufacturing is characterized by the linear mate- 
rial flows from material procurement to final consumption. 
DSS Database 
Overview 

The DSS Database 12 is internal to the DSS 10 imple- 
mentation. The main objective of the DSS Database 12 is to 
support the execution of the decision support functionality 
of the DSS 10. It contains the synthesized data drawn from 
a variety of external supply chain information sources and 
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and networking platform and hence applicable to a variety of 
environments. 

The structure maintains the design of the horizontal layers 
for its key system elements while its functionality Ls more 
aligned vertically. The overall DSS 10 interfaces with the 
Supply Chain Information Systems 15 through the data 
exchanges between these systems and the DSS Database 12. 
The DSS 10 has a User Interface 18 to interact with end 
users through interactive and visual data exchange. Thus, the 
main body of the DSS 10 includes the following horizontal 
layers: User Interface 18; Decision Support Frames 16; 
Supply Chain Frame Manager 24 (Client and Server); Model 
Engine 20; and DSS Database 12. 

As previously mentioned, the above layers of the DSS 10 
can be partitioned into client and Server Modes. The system 
layers within the Client Mode 30 serve an interpretive role 
between the system data and analytic processing support and 
the specific end user's decision support needs. Those layers 
under the Server Mode 32 contain system functionalities 
common to a diversity of users and decision support 
problems, and usually require more dedicated, higher per- 
formance system processing capabilities. 

To capture and process a user's decision support request, 
the DSS 10 will invoke a vertical decision support thread 40 
going through visual objects of a User Interface 18, decision 
logic and what- if scenario manager in a Decision Support 
Frame, Supply Chain Frame Managers, models or analysis 
routines in the Model Engine 20 and appropriate data 
elements in the DSS Database 12. An example of a decision 
support thread 40 is shown by the bi-directional arrows in 
FIG. 3. 

Relevant Supply Chains 

The detailed discussion and specifications for the Deci- 
sion Support Frames 16 provided in this document are 
generic in nature so that the functionality and system fea- 
lurcs In the resulting DSS 10 can cover decision environ- 
ments for a diversity of supply chains. 'l"hc system specifi- 
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a set of data unique to the DSS 10 but not available in any 
existing Supply Chain Information Systems 15. An example 
of such unique data is the data derived through the analysis 
of synthesized data. The DSS Database 12 can be interfaced 
to the Supply Chain Information Systems 15 to retrieve the 
required data and provide updated data, as needed. 

The Database Management System 14 (DBMS) commu- 
nicates with the Model Engine 20 to provide the input data, 
and update the database 12 based on the output of the Model 
Engine 20. In general the DBMS 14 does not duplicate the 
transaction -based functionality that is typically featured in 
the Supply Chain Information Systems 15, unless it is 
critical for decision support needs. 
Data Representation Scheme 

Choosing an appropriate data representation is important 
to ensure data consistency, and rcconfigurabilily. Structural 
Data Representation. 

A structural data representation of the data in various data 
spaces 50, 52 and 54 (see FIG. 4) is used to model the 
elements of the supply chain that are relatively static. 
Specifying these data elements typically specifies the infra- 
structure of the supply chain. At the highest level of 
abstraction, four principal nodes (see FIGS. 5 and 6) in the 
supply chain 58 are identified: 

Demand node 59: The customer demands are character- 
ized at this node. 
Inventory Node 60: Inventories of key components or 
finished goods are identified to be at these inventory 
nodes. 

Production Node 61: Production resources (or finished 
goods supply) are located at production nodes. 

Component Supply Node 62: The supply points of key 
components are characterized at the component supply 
nodes. 

'ITiesc structural data elements are spatially distributed along 
the supply chain 58 (see FIG. 5). 'Ilic relationship between 
these nodes is preferably modeled in the form of a network. 
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The network characterization is a collection of links thai 
connect the principal nodes. A link establishes a logical 
relationship between two nodes, which may have several 
attributes such as distance between the two nodes, transpor- 
tation lead time, etc. 

Id greater detail, the structural data elements and their 
relationship to the principal nodes arc described as follows. 
Key components 63 are supplied by comfwnent suppliers 64 
tied to specific component supply nodes 62. Production 
resources 65 produce the various products 66. The produc- 
tion resources can be aggregated into production resource 
groups 67, and are located at production nodes 61. Products 
66 are the end items that are produced and, based on their 
various atlributes, can be grouped into various product 
groups 67. These products arc stocked at various stock 
locations identified with inventory nodes 60 and inventory 
headers 68. Customers 69 can be grouped by various criteria 
into customer groups 70 and demand various products. 
Customers 69 are located at the demand nodes 59. Markets 
71 are defined for a cross-section of customers and products. 

A similar slmcture can be provided for the repair chain as 
illustrated in FIG. 6. 

Such a data representation in the form of a network of 
nodes and the abihty to group the various constituent 
elements, provide the flexibility to specify and reconfigure a 
variety of supply chains. 
Process Data Representation 

In addition to the structural elements, the data associated 
with the various processes in the supply chain need to be 
represented. These process data elements are relatively 
dynamic with respect to time and the associated processes 
transform data related to the various structural elements. To 
characterize the process data, we introduce a few additional 
data structures. 
Data Space 

A data space is a fundamental domain to characterize 
basic data elements associated with the supply chain man- 
agement: demand, supply and inventory data. The data 
spaces 50, 52 and 54 tie the ^nictural data to the process 
data. It has three principal dimensions: Product/Component; 
Time; and Node related structural element. As the node- 
related structural element can be a customer, an inventory 
location, or a production resource. The data in each data 
space can be at any resolution (in terms of level of 
aggregation) along the three dimensions and can be 
expressed as a quantity or value. Thus, each point in the data 
space characterizes the resolution of the product (or 
component), the time and the nodc-relatcd structural cle- 
ment. For example, when describing the aggregate produc- 
tion plan data, a product can be at the resolution of product, 
lime at a resolution of week, and the node-related structural 
element (Production resource in this case) at a resolution of 
production resource group. On the other hand, in describing 
bottom-up forecasts, a product can be at the resolution of 
product, time at a resolution of month, and node related 
structural element at the resolution of customer. 

We identify three principal data spaces associated with 
supply chain management: Demand Data Space 50; Inven- 
tory Data Space 52; and Supply Data Space 54. These data 
spaces are pictorially represented in FIG. 4 and are 
explained next. 
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Demand Data Space 50: This data space 50 has three 
dimensions: Customer; Product; and Time. Customer can be 
at a resolution of customer or customer group or demand 
node. Product can be at the resolution of product or product 
5 group. Time can be at a resolution of day, week, bi-week, 
month, bi-month, quarter or year. 

Supply Data Space 52: This data space 52 has (he fol- 
lowing three dimensions: Production Resource; Product/ 
Component; and Time. Production resource can be at a 
resolution of production resource, production resource 
group, or production node. Product/Component can be at the 
resolution of component, product or product group. Time 
can be at a resolution of day, week, bi-week, month, 
15 bi-month, quarter or year. 

Inventory Data Space 54: This data space 54 has the 
following three dimensions associated with it: Inventory 
Location; Product/Component; and Time. Inventory loca- 
tion can be at a resolution of stock location or inventory 
20 node. Product/Component can be at the resolution of 
component, product or product group. Time can be at a 
resolution of day, week, bi-wcek, month, bi-month, quarter 
or year. 

A decision process relates or transforms data either within 
a data space or between data spaces. For example, aggregate 
production planning transforms data from the supply space 
to inventory space and vice versa. We will employ this data 
space representation to specify the various decision pro- 
cesses in supply chain management. 

The DSS Database 12 comprises structural information 
(information related to relatively static information such as 
product groups, market groups, supply chain network, etc.), 
and process information (dynamic information related to 
demand, production plan, etc.). FIG. 5, previously 
discussed, graphically represents the structural data tables 
for the manufacturing supply chain. 

Similarly, the DSS Database 12 for the equipment repair 
supply chain (see FIG. 6) comprises structural information 

40 (information related to relatively static information such as 
equipment, repair resources, supply chain network, etc.), 
and process information (dynamic information related to 
usage, requirements, repair plan, etc.). Again, the structural 
elements are flexibly collected into different groups to allow 

45 users to analyze data at various resolutions. For example, 
equipment of the same age can be grouped together to 
analyze the effect of age on repair requirements. FIG. 6 
graphically represents the siruciural data tables for the 
equipment repair supply chain. 

50 The process data in the DSS Database 12 are contained in 
two closely related table type data structures (see below): (I) 
header file that specifies the resolutions and values on the 
relevant dimensions of product, customer, time, resource, 
and item, (ii) corresponding data file which contains the 

55 actual data at the resolutions and values specified in the 
header. 'Die process data are preferably stored in these two 
tables (Tabic 2, Table 3), rather than one consolidated table 
(Table 1), to avoid redundancy and updating anomalies. A 
loss- less join of the header and the data tables wiU result in 

60 the consolidated table (Table* I). The following example 
demonstrates this point. 
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A single consolidated table with redundancy fnot in normal form ) 
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TABLE 2 



Header tabic that provides the scries information 
and the various identifiers 



Orientation Qistonier Product Time Date 
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Type of the data field; and Brief description of the data fields 
(this includes the choice of values for Ihe data in this field, 
if applicable). 

The specifications of the data tables for the manufacturing 
and equipment repair supply chains can be found in Appen- 
dices A and B, respectively. 'ITie list of the preferred tables 
in the DSS Database 12 for these chains is as follows: 
Aggregate Production Plan Data; Aggregate Production Plan 
Header; Budget Data; Budget Header; Calendar; Compo- 
nent; Component Accommodation Matrix; Component 
Requirement Data; Component Requirement Header; Com- 
ponent Supplier; Component Supply Contract; Component 
Supply Node; CPRD Table; Customer; Customer Group; 
Customer Group; Definition; Customer Orders; DataField 
Definition; Demand History Data; Demand History Header; 
Demand Node; Demand Orientation Data; Demand Orien- 
tation Header; Domain; Domain Definition; Feature 
Choices; Forecast Data; Forecast Header; Freight Rate; 
Inventory Data; Inventory Header; In\'entory Node; Inven- 
tory Parameters; Market Data; Market Header; Material 
Delivery Schedule Data; Material Delivery Schedule 
Header; Planning BOM; POS Data; POS Header; Product; 
Product Features; Product Group; Product Group Definition; 
Production Accommodation Matrix; (Production Capacity 
Data; Production Capacity Header; Production Matrix; Pro- 
duction Node; Production Requirements Data; Production 
RequiremenLs Header; Promotion Data; Promotion Header; 
Resource; Resource Group; Resource Group Definition; 
Sales Requirements Data; Sales Requirements Header; Sce- 



TABLE 3 



Data tabic that contains lererences to the header 
table aiKi the time series data 
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6/1/96 


20 


2 


7/1/96 
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565 
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Data Tables 

'ITie data tables in the DSS Database 12 are preferably 65 
specified as follows: Name of the table; Brief description of 
the data contained in the table; Identifier for the data fields; 
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nario; Scenario Data; Compatibility; Scenario Definition; 
Setup Matrix; Supply Chain Network; Supply Order Data; 
Supply Order Header; Temporary Product List; VMR Con- 
tract; VMR Data; and VMR Header. 
Core Reports 

The present invention preferably provides core reports 
that support business decision processes by characterizing 
the link between the various data elements and processes. 
They synthesize the data and information used in the deci- 
sion making processes. Associated with each key business 
process, wc will demonstrate the data flow relationships that 
are used to construct the various forms and reports. Some of 
the preferred forms and reports relevant to the DSS 10 are: 
Sales Plan; Customer- Demand History; Production-Sales- 
Inventory Plan; Master Production Plan; Production Capac- 
ity Plan; Replenishment Schedule; Customer-DC Assign- 
ment; and Supply-DC Assignment. 
Decision Support Frames 
Overview 

From a user perspective, a Frame 16 is an integrated 
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the display 74 contain the form and style of the User 
Interface 18. The decision logic 76 permits the assembly of 
models and analysis routines and the associated data to 
address the set of related decision problems. For example, in 
the case of the PSl Planning Frame 160, the user dialog 72 
and display 74 are customized to the specific needs of the 
PSI planning process, which further determines the design 
of the User Interface 18 associated with the PSI Planning 
Frame 160. Users will interact with the PSI Planning Frame 
160 through the User Interface 18 by formulating Scenarios 
78. Based upon the Scenarios 78, the decision logic 76 in the 
PSI frame may assemble models and routines from the 
Model Engine 20 along with the associated data. The 
decision logic 76 in a frame interacts with the Supply Chain 
Frame Manager 24 to execute the models and routines. The 
Supply Chain Frame Manager 24 then provides the perfor- 
mance feedback to the user. 

Decision Processes in the Manufacturing Supply Chain 
The decision processes in the is manufacturing supply 



decision support environment based on an abstraction of the '=hain are depicted in FIG. »- We have identified five decision 



supply chain designed to address a set of related decision 
problems within a decision process. A Frame 16 is therefore 
defined based on the vantage point or view point of the users 
along a supply chain. This implies that a frame exists if and 
only if there are users with specific needs in the supply 
chain. 

From a system perspective, a Frame 16 is a mechanism 
that unifies the user dialog and display, the models and 
analysis routines, and data in a maimer that is consistent to 
support the underlying supply chain abstraction of the user. 
A summary of the frame concept from both a user and a 
system perspective is shown in Table 4. 

TABLE 4 



Frame Concept: User's 


and System Perspective 


User Perspective 


System Perspective 


An environment to address 


It is a subsystem that 


a collection of related 


processes user requests in 


dccbion problems. 


the form of Scenarios. 


Always associated with a 


It consists of a 


decision maker or a group 


consistent set of process 


of derision makers. Frame 


and data models. 


exists if and only if 




there are decision 




tnakers. 




Has a unique perspective 


It unifies the User 


of the underlying supply 


[nter&ce, Model Engine, 


chain based on the 


and DSS Database elements 


responsibility of the 


that are speciAc to a 


decision makers 


decision making process. 


associated with the 




frame. 




Enhances the coordination 


A convenient client-server 


of decision making 


architecture thai enables 


implicit in the 


the emnsion of the DSS 


defiaitian of the frame. 


fuDctionaiity. 


Enforced through 




organizational 




accountability and 




responsibilities. 
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Frame Architecture 

'ITie high level design of a Decision Support Frame 16 and 
its interaction with the User Interface 18, the Supply Chain 
Frame Manager 24, the Model Engine 20, and the Database 
12 is iliustraied in FIG. 7. A Frame 16/72 is the abstraction 
of the supply chain from a user's point of view. It essentially 
contains as its design elements a user dialog 72 and user 
display 74 and a decision logic 76. 'I'he user dialog 73 and 



processes closely associated with the key decision makers 
and potential users in a supply chain; Overall Supply Chain 
Management 80, Demand Management 81, PSI 
(Production-Sales-Inventory) Planning 82, Supply Manage- 
ment 83, and Vendor Managed Replenishment (VMR) 84. 
Overall Supply Chain Management 

A supply-chain-wide view and the necessary Manage- 
ment 80 is recognized by all levels of the management as 
being vital to managing the business. However, decision 
makers at different levels and points along the supply chain 
are primarily motivated by their individual roles and respon- 
siT^ilities. The broader a decision maker's responsibilities, 
the more likely the decision maker is interested in employ- 
ing decision support capabilities that target the entire supply 
chain. The user requirements discussed below for decision 
support are posed from a supply-chain-wide perspective. 
Given the uncertainty in the medium- to long-term sales 
forecasts, detenmine whether or not the enterprise should 
expand, maintain or reduce its production capacity and/or 
40 stocks for the critical components. When changes in busi- 
ness conditions impact one part of the supply chain, assess 
the potential impact on the other parts of the supply chain. 
Given different future business scenarios, determine their 
financial consequences across the supply chain. For the 
45 enterprise's supply chain which inclutfcs major retailers, 
determine ihc appropriate division of responsibilities for all 
partners in the supply chain. Develop and implement per- 
formance incentives that will enhance and encourage 
supply-chain-wide thinking and decision making in the 
50 enterprise. 

Demand Management 

Demand Management 81 is the process by which the 
customers' requirements are characterized with the specifi- 
cation of prevailing uncertainty. 'ITie process involves the 
development and maintenance of medium-term customer 
(botlom-up) forecasts. Tht»e forecasts are initially devel- 
oped in periodic joint meetings or communications between 
the decision makers of the enterprise and the customers. 
Subsequently, these forecasts are input into the enterprise's 
60 supply management system to obtain product allocation 
approval (place-keeping order). As the actual purchase 
orders arrive, (he enterprise attempts to fulfill the require- 
ments to their customers' satisfaction. We have identified the 
user requirements discuss below for decision support for this 
process. Synthesize information from different sources in 
order to manage (he demand requirements eflcclively, e.g., 
accessing point-of-sales (POS) data and comparing these 
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with shipment history and customer forecasts. For key 
customers, develop customer-specific sales forecasts based 
on historical shipment and sell-through data. Link POS data, 
where available, to (he historical promotion information to 
analyze the real impact of promotion activities on demand, 
as opposed to relying on the estimates provides by the 
retailers. 
PSI Planning 

PSI Planning 82 is a process to determine a set of feasible 
sales, production and inventory requirements for medium to 
long-term capacity and resource planning for the logistics 
operations. At the beginning of each fiscal year, an initial 
PSI plan can be developed based on the long-term lop-down 
sales forecast and budget plans. The planning process then 
becomes a continuous effort to update the existing PSI plan 
to accommodate the changes in the requirements before and 
after a scries of monthly PSI planning meetings whose 
participants include decision makers representing all key 
functional areas at the enterprise. The meetings integrate the 
inputs from various sources, resolve possible conflicts, and 
balance the concerns of different fiinaions in order to 
reconcile, develop and approve a new set of feasible sales, 
production and inventory requirements. The process repre- 
sents a focal point for the entire logistics planning process, 



20 



bility to assist the planners in translating the production 
requirements into critical component requirements, i.e., 
components featured in the planning bill of materials. 
Vendor Managed Replenishment (VMR) 

VMR 84 is a process in which the supplier takes on the 
responsibility of managing the inventory at the customer site 
for the products it supplies. This process operates on point- 
of-sales demand as opposed to demand forecasts provided 
by the customers. VMR involves formulating the contractual 
agreements between the enterprise and the retailers as well 
as determining the operating parameters such as shipment 
quantities and replenishment frequencies. We have identi- 
fied the user requirements discussed below for decision 
support for this process. Develop a strategic analysis tool to 
determine mutually beneficial VMR contracts based on 
financial and logistics factors. Develop the replenishment 
plan based on factors such as sell-through and inventory 
information provided by the retailer, promotion activities, 
product availability and transportation cost trade-ofife. 
Decision Processes in the Equipment Repair Supply Chain 
Overview of the Equipment Repair Supply Chain 

The equipment repair supply chain 90, as depicted in FIG. 
9, includes the operating location 92, i.e., the point-of-use, 
the repair shop 94, and the component suppliers 96. In an 



and interacts and coordinates with all major decision making 25 equipment repair supply chain, the demand (or the 



processes. We have identified the user requirements dis- 
cussed below for decision support for this process. Generate 
market trend forecasts by product categories for the enter- 
prise as well as the entire industry. Such forecasts will be 
based on available shipment history, industry survey data 30 
and influential economic indicators. Generate forecasts for 
new products and managing product transitions. Facilitate 
development of medium-term top-down and bottom-up 
sales forecasts for the enterprise. Facilitate development of 
production plans and the associated requiremeols plans for 35 
critical components. Evaluate the effects and understand the 
implications of specific changes in the sales or production 
plans. Conflict resolution mechanisms arc needed to adapt 
and maintain these plans. Identify those products that would 



"requirements") arc generated by equipment failures. When 
equipment faik, the failed module is replaced from the stock 
at the operating location 92, and the failed module is 
eventually sent to the repair shop 94 for repair. A module is 
made up of repair items which in turn are made up of 
components. At the repair shop 94, the repair is carried out 
by the repair resources (people and machinery). During the 
repair process at the repair shop 94, certain repair items and 
components are replaced. Based on the repair needs, repair 
items and components will be ordered from the sources of 
supply by the repair shops. 

Equipment Operating Location 92: At the equipment 
operating location 92, personnel may replace only certain 
repair items of the module, instead of the whole module 



be affected by the shortage of certain critical components; 40 'Iliese replacement repair items may come from the stock or 



one possible approach is to use an implosion tool on the bill 
of materials. Provide a formal mcchanisra to determine and 
re-adjusi appropriate inventory levels for various products. 
Supply Management 

Supply Management 83 is a process to determine the 
production (supply) plan to meet the production (supply) 
requirements generated by the PSI Planning process. The 
process involves component procurement and factory pro- 
duction planning based on the PSI plans and their changes. 
At the beginning of the process, the production line capaci- 
ties arc created based on long-term product plans, i.e., 
planned new product release. 'Ilie process continuously 
updates the production (supply) plan based on changes in the 
production (supply) requirements generated in the PSI pr3- 
cess. We have identified the user requirements discussed 
below for decision support for this process. Determine the 
feasibility and the economic viability of changes in the 
production (supply) plan, when changes occur in the PSI 
plans. 'ITiis requirement is motivated by trade-offs between 
the PSI process and the production (supply) planning pro- 
cess. Evaluate possible options to accommodate changes in 
the production requirements, after the line structure and 
capacity are determined. Such an analysis Ls a requirement 
of the factory planner. Develop an aggregate level represen- 
tation of the production line capacities so as to help the 
planners in developing aggregate production plans or check- 
ing production capacity. I>evclop a rough-cut analysis capa- 
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from other failed modules. This process encourages consoli- 
dation of failed modules at the operating location. In the 
consolidation process, the broken repair item of a broken 
module is replaced by a good repair item from another 
broken module. This process may be motivated by the 
slnjcture of the repair cost function and the need for quick 
repair. In some cases, due to the fixed costs of sending 
individual modules to the repair shop, modules are batched 
to a certain level, before they are sent to the repair shop for 
a complex overhaul. 

Repair Shop 94: The repair shop 94 is responsible for all 
the major repairs. The type of repair to perform is driven by 
the level of good modules at the repair location. When good 
modules are sent from tfie repair shop to the operating 
location, the stock level may drop below the target level, 
thus triggering a repair request to bring the stock level up to 
the target level. 'ITiis target level is determined with the 
objective of maximizing the equipment availability and 
minimizing the repair costs. Component and capacity 
reqxiirements corresponding to a repair request should be 
feasible with respect to component availability and resource 
capacity levels at the repair shop. 
Parallel With the Manufacturing Supply Chain 

We recognize the operational differences fjetween manu- 
facturing and equipment repair supply chains. However, the 
equipment repair supply chain has clear parallelism with the 
manufacturing supply chain where the repair items corrc- 
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spond to products and coraponents correspond to materials. 
Equipment operating locations are similar to retailers and 
equipment is like customers. The repair shop is analogous to 
a production facility. As modules are made up of repair 
items, modules correspond to product groups. The repair 
requirements management process is analogous to demand 
management, and repair supply management to supply man- 
agement. Similar to the PSI process, there exists a recon- 
ciliation process in the equipment repair supply chain to 
ensure balance between requirements and supply. 
Application to a National Defense Application 

For a national defense application, the following nomen- 
clature is used. The equipment located at various operating 
locations are the aircraft operating at the various bases. The 
modules correspond to the Line Replaceable Units, or LRUs 
and the repair items correspond to Shop Replaceable Units 
(SRUs). The failure of an LRU, caused by the failure of its 
SRU, renders the aircraft unavailable. The function of the 
base is lo provide immediate support to the aircraft located 
at that base, with the objective of maximizing availability of 
aircraft. For that purpose, bases stock good units of replace- 
able items, called serviceables, so as to be able to replace a 
failed U^U of an aircraft immediately. Abase, usually, is not 
involved in major repairs. Instead, it implements a consoli- 
dation policy (replacing the defective SRU of a newly failed 
LRU with a good SRU of an already defective LRU), which 
gives the base the ability to manage the repair requirements 
of the depot. Managing the repair requirements refers to 
deciding when and which defective items the base will send 
to the depot for repair with the objective of maximizing the 
availability of aircraft located at the base and minimizing 
total cost of repair (which includes a fixed cost component). 

A depot is responsible for all the major repairs. The type 
of repair to perform is driven by the level of good repairable 
items at the depot. When good repairable items are sent from 
the depot to the base, the stock level may drop below the 
target level, thus triggering a repair request to bring the stock -^^ 
level up to the target level. This target level, also called the 
Consolidated Serviceable Inventory (CSI) level, is deter- 
mined by the depot with the objective of maximizing its 
service level and minimizing its repair costs. Component 
and capacity requirements corresponding to a repair request 
should be feasible with respect to component availability 
and resource capacity levels at the depot. 

Table 5 below presents the analogy and nomenclature 
between the equipment repair supply chain, and the manu- 
facturing supply chain with examples from defense and 
commercial environments. 

TABLE 5 



Analogy and aomcnclature between equipment 
repair and n^anuFacturing supply chaina 
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Decision Proces.ses in the Equipment Repair Supply Chain 
'Rie supply chain comprises (see FIG. 9) the following 
three decision prcx;csscs: Requirements Managcmcnl Pro- 



cess 98; Requirements-Supply Reconciliation Planning Pro- 
cess 100; and Supply Management Process 102. 
Requirements Management Process 

The Requirements Management Process 98 concentrates 
on the activities associated with requirements estimation. 
The objective of this process is to estimate future repair 
requirements generated by equipment failures. Equipment 
has several repairable parts and equipment failures are 
caused by failures of the repairable parts. Hence estimating 
future requirements refers to the process of estimating 
failures of the equipment and of the repairable parts that 
caused the failures. This is done to estimate repair lime 
requirements (determined in Requirements-Supply Recon- 
ciliation Planning Process) and equipment availability at 
equipment locations, both of which depend on the part that 
has failed. 

Requirements can be analyzed in two levels: Lower level 
requirements, called the Raw Requirements, corre^ond to 
all repair requirements of the equipment and upper level 
requirements, called the Consolidated Requirements, corre- 
spond to requirements requested from the repair shop, since 
equipment locations may prefer accumulating their repair 
requirements and sending them to the repair shop according 
to certain rules instead of sending them as they occur, or may 
prefer carrying out minor repairs within the location, with 
the aim of reducing the fixed and variable costs of repair. In 
the manufacturing analogy, raw requirements would corre- 
spond to Point of Sales (POS) data and consolidated require- 
ments to retailer order data from the production facility. 

Two different estimation approaches that have been used 
in this process to estimate consolidated requirements are: 
Bottom-up Estimation Approach; and Top-down Estimation 
Approach. 

The bottom-up estimation approach estimates the raw 
requirements first and then generates the consolidated 
requirements from raw requirement estimates. In order to 
estimate raw requirements, relationships are determined 
between failure rates and activity schedules of the equip- 
ment. For example, the time to failure of an equipment can 
be a function of the number of hours it has operated and its 
maintenance schedule. Once the relationships between fail- 
ure rates and activities are established by regression or time 
series models, future failure rates can be estimated based on 
the planned activity schedules of the equipment. Given the 
45 estimated raw requirements, the next step is to go to the 
upper level and estimate consolidated requirements, that is 
requirements as seen by the repair shop (assuming that 
repair shop does not have access to raw requirements data). 
Consolidated requirements depend on what frequency the 
50 operating location will send its repair requests to the repair 
shop. This is analogous to the inventory replenishment 
policy of a retailer in a manufacturing system. In deciding on 
the type and parameters of the inventory replenishment 
policy, the facility will use several conflicting performance 
55 measures such as minimizing total repair cost and maximiz- 
ing availability of the equipment. Thus, given the invenlory 
replenishment policy of the facility and estimates of its raw 
requirements, its consolidated requirements can be esti- 
mated. 

'Yhc top-down estimation approach makes use of histori- 
cal data to estimate consolidated requirements. Statistical 
forecasting techniques can be used lo support this process. 

The two estimates obtained by bottom-up and lop-down 
approaches are compared, analyzed and reconciled to gen- 
erate final estimates for consolidated repair requirements. 
Tlie output of this process is the estimated consolidated 
requirements for an equipment operating location. 
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Requirements-Supply Recoociliation Planning Process 

The second process is the Requirements-Supply Recon- 
ciliation Planning process 100 that aims at developing an 
integrated repair plan for the repair shop through a recon- 
ciliation process. First, the type and parameters of the repair 
policy of the repair shop are to be deiermined. Aggregate 
repair requirements are generated based on the repair policy 
of the repair shop and estimated consolidated requirements 
for all facilities. The next step is to generate an aggregate 
repair plan based on repair time estimates for each repairable 
part and the aggregate repair rcquirenicnts. Feasibility of the 
aggregate repair plan is checked with respect to resource 
constraints which are repair resource capacities and key 
component availability. If the aggregate repair plan is twt 
feasible with respect to resource constraints, then causes for 
infeasibility are identified and the infeasibility is removed by 
cither changing the level of the resource constraints or 
moving aggregate requirements forward or backward in 
time. This procedure is repeated until an aggregate repair 
plan that is feasible with respect to resource constraints is 
attained. The supply management 102 (see FIG. 9) is a 
process to determine the repair plan considering repair 
people, test equipment and key components. It starts by the 
translation of the aggregate repair plan into a detailed plan 
concerning repair resources (repair persons and test 
equipment), and component requirements. Based on these 
requirements and the capacity constraints for the repair 
resources, repair peisonnel and key components, a detailed 
repair plan is developed using an optimized based modeling 
approach. The detailed repair plan is used to generate the key 
component delivery schedule to be transmitted to the com- 
ponent suppliers. In addition, the supply management pro- 
cess 102 is also concerned with the development of appro- 
priate procurement policies for key components in terms of 
identifying the policies, and deriving the corresponding 
policy parameters. 
Basic Frames 

The basic Frames 16 of the present invention collectively 
provide coverage for the overall supply chain. The specific 
instances of these Frames 16 in a particular DSS 10 imple- 
mentation depend largely on the constituent supply chain, 
the underlying business processes, and the organizational 
structure. Table 6 below lists the Decision Support Frames 
16 in the context of manufacturing and equipment repair 
supply chains. 

TABLE 6 

Decision Support Prairies in the Cootcxt 
of Manufacturing and Equipment Repaif Supply Chains 



Manufacturing Supply 
Chain 



Equipment Repair Supply 
Chain 



Demand Management 
PSI Planning 

Supply Management 
Vendor Managed 
Replenishment 
Finished Goods 
DistrtbuiioD Netwofk 
Design 



Requirements Managemeat 
Requirements-Supply 
Reconciliation 
Supply Management 



Specification of the Basic Frames 

To specify each basic Frame 16, we use influence dia- 
grams to map the modules in the Model Engine 20 and the 
Data Spaces to the frame. We use process flow diagrams to 
outline the high level design of the logical relationship 
among the key data tables, the modules and the basic Frames 



16. We also discuss how to support key functional require- 
ments in each frame. To complete the specification of the 
basic Frames 16, we use data flow diagrams to map the data 
tables to the core reports in each frame. The legend for the 
5 process and the data flow diagrams which will be discussed 
herein after is shown in FIG. 10. 
Demand (Requirements) Management Frame 

The Demand Management Frame 130 supports the 
demand management decision process described here. 
10 Manufacturing Supply Chain 

Module and Data Space Association 

FIG. 11 shows the participating modules and the associ- 
ated data spaces for this frame. 

The Demand Management Frame 130 requires the par- 
ts ticipation of two modules: the Sales Forecasting and Plan- 
ning (SFP) Module 132 and the Market Data Analysis 
(MDA) module 134. The SFP Module 132 in the Demand 
Management Frame 130 essentially operates in the D data 
space, i.e., it transforms data within the conceptual demand 
20 data domain. The MDA Module 134 in the Demand Man- 
agement Frame 130 operates in the I and the D data spaces 
and relates the I data space to the D data space, i.e., it may 
transform data within the individual D data space as well as 
transform data from the I data space to the D data space. The 
25 data space representation of the Demand Management 
Frame 130 is the union of the data space representations of 
each participating module, and the interactions among par- 
ticipating modules. 
The high level representation of FIG. 11 can be comple- 
30 mcnted by the process flow diagram for this frame, 
described next, that will detail the connections between the 
constituent modules and the associated data tables. 
Process Flow 

The process flow diagram for the Demand Management 

35 Frame 130 is shown in FIG. 12. The modules, data tables, 
and the principal activities within the scope of this frame are 
clearly marked by the grooved double-lined border. Only the 
data tables that are updated by the frame arc considered to 
be within the scope of the frame 130. Other frames, activities 

40 and data tables that are related are also shown for complete- 
ness. The Order Fulfillment 149, that is out-of-scope of the 
Demand Management Frame 130 but related to it, is shown 
separately in FIG. 13 for purposes of clarity. This represen- 
tation of interaction between Frames 16 is consistent with 

4S the interaction between decision processes shown in FIG. 8. 
The Demand Management Frame 130 supports the func- 
tional requirements described below. Demand 
Characterization — Demand data from various sources such 
as Demand History Data 136, POS Data 138, Market Data 

50 140, and Promotion Data 142 as well as top-down and 
bottom-up Forecast Data 146 obtained by buyers and 
account managers will be consolidated and synthesized by 
the MDA Module 134 and the SFP Module 132. Boitom-up 
Demand Forecasting — Demand Review 144 consolidates 

55 demand information received directly from the customer 
along with the input from the MDA Module 134 and then 
develops Demand Orientation Data 148. The SFP Module 
132 will then use Demand Orientation Data 148 as well as 
other inputs, e.g. Promotion 142 and POS 138 Data, to 

60 develop the customer-centric bottom-up forecasts in Fore- 
cast Data 146. Top-down Forecasting — ^The SFP Module 
132 will use market and industry-wide trend analysis per- 
formed by the MDA Module 134 along with the enterprise's 
shipment history to generate the product-ceniric top-down 

65 forecasts in Forecast Data 146. Sales l^moiion Analysis — 
'Die MDA Module 134 reviews the demand history from 
POS Data 138 and l>:mand History Data 136 along with the 
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customer promotion information from Promotion Data 142 
to analyze the impact of promotions on sales. The results of 
such an analysis are then used to help adjust sales forecasts 
to account for promotions. Forecast Performance 
Evaluation — Using Demand Orientation Data 146, Demand 5 
History Data 136 and Promotion Data 142. the SFP 132 and 
MDA Module 134 can evaluate the quality of enterprise's 
forecasts and the customer projections. 
Data Flow 

The data flow diagram for the Demand Management to 
Frame 130 is shown in FIG. 14. The Demand Management 
Frame 130 generates two of the core reports listed earlier, 
namely, the Sales Plan 152 and the Customer- Demand 
History 154. For each core report, the associated data tables 
arc shown. The dashed line indicates the influence of an 15 
out-of-scope (with respect to the Demand Management 
Frame 130) data tabic in the development of the report. For 
example, the Customer Orders data table 150 is out-of-scope 
of the Demand Management Frame 130 but influences the 
Customer-Demand History report 152. 20 

Demand Management is the process in which the user 
determines future requirements based on past requirement 
history and general information related to the supply chain. 
In the context of the manufacturing environment Demand 
Management supports the analysis of past demand and of 25 
market trends as weU as the development of future forecasts. 
For the repair environment the tenm Requirement Manage- 
ment is used in place of Demand Management. Requirement 
Management is the process where future requirements are 
estimated based on an analysis of each equipment's activity 30 
and 00 the projection of past requirement history. 

In the manufacturing context, Demand Management 
regroups the set of processes by which the user analyzes 
Market Data 140 and past demand history for the purpose of 
estimating future demand requirements. The outputs of 35 
Demand Management include the analysis of past history, 
future forecasts, the analysis of special activities such as 
sales promotions, and the analysis of forecast errors. Two 
critical outputs of Demand Management are two different 
medium term forecasts corresponding to two difl^erent views 40 
on the dynamics of the processes that generate future 
requirements: the customer centric forecast — generated at 
the product level for each customer it incorporates the 
estimations of future demand provided by each customer 
(Bottom-up Forecast); and the product centric forecast — 45 
generated at the product level, it incorporates the impact of 
market and industry-wide trends on futiu'c demand for each 
product group (Top-down Forecast). 'ITiese two types of 
forecast are generated using: Historical projection of past 
demand; Future orders information; Analysis of the dynam- 50 
ics and characteristics of the overall market and main 
competitors; and Analysis of the impact of future special 
commercial activities such as sales promotions. These 
analyses and projections are grouped in five functional 
requirements that are detailed in the rest of this section: S5 
Demand Characterization, Bottom-up Demand Forecasting, 
Top-down Demand Forecasting, Sales Promotion Analysis, 
and Forecast Performance Evaluation. 

Other frames such as production, sales and inventory 
(PSl) or vendor managed replenishment (VMR) may 60 
directly or indirectly use the output of Demand Manage- 
ment. 

Demand Characterization 

'ITie objective of Demand Characterization is to provide 
the user with an environment where (s)he can access, 65 
analyze and synthesize demand data from difl'erent sfjurccs. 
'Ricscdaia include: Sales History data (thai include POS and 



shipment data). Inventory data (relative to the inventory 
position of its product at the customer's stocking points), 
and Market Data 140. Market Data 140 correspond to 
various quantitative information, usually provided by exter- 
nal entities such as Nielsen, that relates to the sales for the 
type of product considered in the entire market. 
Acquire, Display, Edit Data 

Data Acquisition consists of selecting a Data Domain 
(specific pairs of customer and product), and choosing the 
type of data to be displayed (POS, demand history, 
inventory, Market Data 140). Data can be edited and modi- 
fied and saved along with results of analysis in a scenario. 
Analyze & Synthesize Data 
Sales History and Customer Inventory Data 
This involves the operations discussed below. 
Compute, display (tables and graphs), characterize and 
analyze sales history per product/product group or 
customer/customer group (see the MDA Module speci- 
fication discussion for details of models and formulas): 
Volatility of demand, Lumpiness of demand. Trends in 
demand history. Demand pattern changes, and Season- 
ality. 

Compute, display (tables and graphs) and analyze sales 
history statistics for difl'erent levels of aggregation: 
This year vs. last year, Actual sales vs. budget, and Year 
to date vs. balance of Year. 

Compute, display (tables and graphs), and analyze trend 
in Demand Product Mix by product group. 

Parcto analysis of sales (or inventory) to identify ABC 
classification for products (see MDA Module specifi- 
cation for details of formulas). 

Compute and analyze correlation between the demand for 
different product groups. 

Compute, display (tables and graphs), and analyze new 
products and model change-over profiles. 

Compute, display (tables and graphs), and analyze inven- 
tory profile per customer. 

Compute, display (tables and graphs), and analyze trade 
inventory by comparing POS and shipment data. 
Market Data 

This operation involves the operations discussed below. 
Display (tables and graphs) Market Data 140 (volume, 
value, market share) by product ^oup, region, or 
customer group (Nielsen, EIA, etc.). 
Compute, display (tables and graphs) and analyze Market 
Data 140 statistics for different levels of aggregation: 
This year vs. last year. Trend, Actual statistics vs. 
budget assumption, and Seasonality. 
Parelo analysis of competitors (value and volume). 
Create price information: list of competitor products per 
price range. 
Boltom-Up Demand Forecasting 

The objective of the Bottom-up forecasting is to develop 
a customer specific sales forecast based on historical ship- 
ment to the customer, POS information at the customer 
location, and the customer's own forecast regarding its 
future orders. 

Acquire, Display, Edit Data 

Data Acquisition consists of selecting a data Domain 
(specific pairs of customer and product), and choosing the 
type of data to be displayed: shipment or POS (when 
available). 

Forecasts generated in the Bottom-up forecasting frame 
can be saved back to the DSS Database 12 or alternatively 
saved as scenario. 
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Bottom-Up (BU) Forecast Generation 

This operation involves the operations discussed below. 

Input and maintain customer orders: Forward orders, and 
Orientation orders. 

Choose model for statistical forecast. 

Generate and display (tables and graphs) statistical fore- 
cast at different level of aggregation (POS or Shipment 
data): Customer group. Individual customers for all 
products, and Individual customers for each product. 

Support integration in BU forecast of expen knowledge 
for optimistic/pessimistic forecast. 

Formulate disaggregation logic of BU Forecast at cus- 
tomer level onto products. 

Incorporate impact of future promotions for customer 
specific promotions. 

Compute, display and edit seasonality factors. 

Review actual seasonality against planned and "com- 
pany" seasonality. 

Disaggregate yearly forecasts onto each period using 
seasonality factors at different levels of aggregation 
(POS or Shipment data): Customer group. Individual 
customers for all products, and Individual customers 
for each product. 

Compute and display (tables and graphs) sales and fore- 
cast statistics; Moving average, Year to dale/balance of 
year. This year vs. last year, and Actual/forecast vs. 
Budget. 

Support comparison of POS and Shipment data for analy- 
sis of change in trade inventory profile. 

Invoke forecast accuracy estimation routine. 
Top-Down Forecasting 

The objective of the Top-down forecasting is to develop 
a product centric sales forecast based on historical demand 
data and industry analysts that accounts for market-wide 
trends. 

Acquire, Display, Edit Data 

The data Acquisition consists of selecting a data Domain 
(specific pairs of customer and product), and choosing the 
type of data to be displayed: shipment or POS (when 
available). 

Forecasts generated in the Top-down forecasting frame 
can be saved back to the DSS Database 12 or alternatively 
saved as a scenario. 
Top-Down (TO) Forecast Generation 

'lliis operation involves the operations discussed below. 

Choose model for statistical forecast. 

Generate and display (tables and graphs) statistical fore- 
cast at different level of aggregation (POS and Ship- 
ment data): market level, product group level, and 
product line level. 

Incorporate industry trend analysis developed in Demand 
Characterization in TO forecast. 

Formulate disaggregation logic of TO Forecast at product 
level onto customers. 

Incorporate impact of future product ^ecific promotions. 

Compute and display (tables and graphs) sales and fore- 
cast statistics: Moving average. Year to date/balance of 
year, This year vs. last year, and Actual/forecast vs. 
budget. 

Compute, display and edit seasonality factors. 

Review actual seasonality against planned and "com- 
pany" seasonality. 

Disaggregate yearly forecasts onto each period using 
seasonality factors at dilTcrenl levels of aggregation 



(POS or Shipment data): market level, product group 
level, and product line level. 
Support forecasting of model change over, and introduc- 
tion of new products. 
^ Invoke forecast accuracy estimation routine. 
Sales Promotion Analysis 

The objective of Sales Promotion Analysis is to analyze 
the impact of promotional activities. It entails maintaining 
the promotion calendar, estimating the impact of future 
promotions and assessing the effect on sales of past promo- 
tional activities. The promotion calendar is a table in which 
the various characteristics of past and future promotions are 
recorded. The knowledge and insights gained in sales pro- 
motion analysis are used in adjusting bottom-up and top- 
down sales forecasts. 

The functional features associated with Sales Promotion 
Analysis are given below. 
Maintain Promotion Calendar and add new promotions: 

Time period of promotion. 
Type of promotion (defined by who initiates the promo- 
tion: firm, retailer, competitor), and Class of promotion 
(defined by the nature of the promotional activity). 
Intensity of promotion: Search and sort promotion 
2j calendar, and Analyze Past Promotions. 

Display sales data along with information of promotions 

under consideration. 
Establish profile for the impact of the sales promotions. 
Analyze promotion(s) effect through regression or time 

series models. 
Partition sales: Display actual sales attributable to normal 

sales, seasonal effect and promotion effect. 
Plan Future Promotions. 

Add promotion in promotion calendar — specify type, 

class, intensity and time period. 
Estimate impact of future promotion based on the impact 
of similar past promotions. 
Forecast Performance Evaluation 

The objective of Forecast Performance Evaluation is to 
assess the accuracy of past sales forecasts. Forecast accuracy 
is an important measure for several purposes: 

It helps the user to refine the forecasting process by 
providing feedback on the ability of different models 
and approaches to forecast future demand; 
It provides a measure of demand variability that is used to 

assess necessary safety stock; and 
It guides attention to those products and customers for 
which demand is difficult to forecast and that require 
special attention. 
Two types of forecast performance evaluations are con- 
sidered: forecast accuracy of one particular version of the 
forecast, and average accuracy of n periods ahead forecast. 

The first forecast performance type provides point esti- 
mations of forecast accuracy, while the second one is an 
average estimation of the accuracy as a function of the 
number of period in advance a forecast is produced. 

The functional features associated with Forecast Perfor- 
mance Evaluation are given below. 
Select data domain. 

Compute and display Forecast errors for Bottom up 
forecast. Top down forecast, and Sales plan (invoked 
from I'SI). 

Maintain Accuracy Matrix for each tj^pc of forecast (table 

of the forecast accuracy n periods ahead). 
Generate exception re[K)rt based on level of forecast error 
for different level of aggregation. 
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Equipment Repair Supply Chain 

In the context of the Equipment Repair Supply Chain ihe 
term "Requirements Management" is used in place of 
"Demand Matiagement" to indicate that equipment gener- 
ates "repair requirements" when it breaks down. 

Requirements Management is the process of estimating 
the future requirements of reparable items at the equipment 
location. This process can be divided into two main sub- 
processes: 

Evaluation of the raw requirements for each equipment; 
and 

Estimation of (he consolidated requirements at the level of 
each location (several pieces of equipment can be 
located at the same location). 

TTiese two approaches can be used to estimate future 
consolidated requirements. 

Bottom-up method: This approach uses a combination of 
two models: (1) the first model estimates the raw 
requirements of an equipment by modeling its failure 
rale as a function of the equipment's activity (or usage) 
and (2) the second model estimates the consolidated 
requirement based on the raw requirements and the 
consolidation policy. 

Top down method: This approach is based on the projec- 
tion of historical data for the consolidated demand. 
To support the two different approaches the functional 
requirements detailed below have been defined. 
Activity Tracking for Raw Requirements Estimation 

This involves the operations discussed below. 

Select and Display Activity Data. 

Maintain Future Activity Data: Planned Equipment 
upgrade/maintenance schedules; and Planned Equip- 
ment usage schedules. 

Analyze Past Activities. 

Review activities: Display historical raw requirements 

data along with activity data. 
Assess impact of past activities using regression or time 

series models. 
Per type of equipment. 
Per type of activity. 

Relate future raw requirements to planned activities. 
Use models of past activities to project the effect of future 
activities. 

Consolidated Requircmeats Estimation Based on Raw 
Requirements (Boltom-Up) 

This operation involves the operations discussed below. 

Select and Display Consolidated Requirement data. 

Formulate, and refine consolidation policy (see SFP Mod- 
ule for explanation regarding consolidation policies). 

Evaluate different consolidation policies based on past 
raw requirements. 

Estimate future consolidated requirements based on cho- 
sen policy. 

Consolidated Requirements Estimation Based on Historical 
Data (Top-Down) 
■^rhis involves the operations discussed below. 
Select and Display Consolidated Requirement data. 
Oioose model for statistical forecast of future usage per 

repair item/repair item group. 
Kalman Hher based algorithm for requirements estima- 
tion (considered appropriate for forecasting equipment 
failures). 

Other statistical forecasting techniques. 
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Generate and display (tables and graphs) statistical fore- 
cast at different level of aggregation: Repair item 
group. Individual Repair item for all equipment, and 
Individual Repair item for each equipment. 
5 Compute and display statistics (tables and graphs) for 
actual and estimated consolidated requirements: Mov- 
ing average. Year to date/balance of year. This year vs. 
last year, and Actuaiyforecast vs. Budget. 
Develop disaggregation logic of consolidated require- 
ments estimation Forecast at repair item group onto 
individual Repair item. 
Users can override algorithm based estimates. 
Requirements Reconciliation and Requirements Plan Gen- 
eration 

This operation involves the operations discussed below. 
Compare and analyze top-down and bottom-up require- 
ments numerically and visually. 
Reconcile the top-down and bottom -up requirements to 
20 generate the requirements plan. 
Use weighted average models. 
Incorporate user's input and override. 
Requirements Estimation Performance Evaluation 
Store top-down, bottom-up and reconciled requirements 
estimates. 

Compute and display Estimation errors for: Bottom up 
requirement estimation. Top down requirement 
estimation, and Reconciled requirement estimation. 
30 Maintain Accuracy Matrix for each type of requirement 
estimation (table of the accuracy o periods ahead). 
Generate exception report based on level of estimation 
accuracy for different level of aggregation. 
Production-Sales-Ioventory Planning (Requirements- 
35 Supply Reconciliation) Frame 

The PSI Planning Frame 160 supports the PSI planning 
decision process described here. 
Module and Data Space Association 

FIG. 15 shows the participating modules and the associ- 
40 ated data spaces for this frame. 

The PSI Planning Frame 160 requires the participation of 
three modules: the Sales Forecasting and Planning (SFP) 
Module 132, the Aggregate Production Planning (APP) 
Module 162, and the Finished Goods Inventory Manage- 
45 ment (FGIM) Module 164. The PSI Planning Frame 160 as 
a whole involves S, I, and D data spaces with iterative data 
transformations among each pair. 
Process Flow 

The process flow diagram for the PSI Planning Frame 160 

50 is shown in FIG. 16. The PSI Planning Frame 160 supports 
the following functional requirements identified for the PSI 
planning decision process: 
Forecast Reconciliation 
The Demand Management Frame 130 supplies the Fore- 

55 cast Data 146 (bottom-up and top-down forecasts). The PSI 
Reconciliation Activity 170 in concert with the SFP Module 
132 revises the top-down forecasts and reconciles the 
bottom-up and top-down forecasts. 'ITiis is an iterative 
process which is shown as the "S" loop (in the top right 

60 quadrant) in the process fiow diagram. If any changes to the 
bottom-up forecasts are warranted, the PSI Planning Frame 
160 interacts with the Demand Management Frame 130 to 
make the necessary changes. 
Inventory Planning 

65 'Die PSI Reconciliation activity 170 in concert with the 
FGIM Module 164 determines the inventory requirements in 
an iterative fashion. Iliis is shown as the "1" loop (in the top 
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left quadrant) in the process flow diagram. The inventory acquires forecasts generated using different methods from 

requirements are written to Inventory Data 182. The FGIM the Demand Management Frame 130. After analyzing these 

Module 164 as part of Ihe PSI Planoiog Frame 160 also forecasts and comparing the results, the user then selects the 

formulates the finished goods inventory policies; the policy most appropriate one to be used. The following features are 

parameters are written to Inventory Parameters 172. 5 identified for this process: Acquire and display forecasts; 

Supply Requirement Planning check forecast errors; Compute and display related statistics 

The PSI Rcconcihalion Activity 170 in concert with the ^^^^ ^nd Select forecasts. Individual descriptions of 

APP Module 160 determines the production requirements th^^^ features are as follows, 

that are consistent with the sales plan and the inventory ^- ^ Forecasts 

requirements in an iterative fashion. This is shown as the "P' ^.^ ^^^^^^^ ^^^^^ ^^^^ ^^^^ 

loop (in the bottom nght quadrant) in the process flow ^ . ^ , , 

diagram. The production requirements are written to Pro- Choose product group: The user speafies the product 

ductton Requirements Data 174. The APP Module 160 as £fO"P of interest. 

part of the PSI Planning Frame 160 also checks aggregate Choose aggregation level: The user specifies the aggre- 

production capacity and key component availability using gation level (e.g. month, year) for data display. 

Production Capacity Data 180 and Inventory Data 182 Import forecasts: The DSS 10 acquires the bottom-up and 

(component availability). top-down forecasts generated in Demand Management 

Production-Sales-Inventory-PIan Coordination p^ame 130 for the selected product group from the DSS 

The PSI Reconciliation Activity 170 interacts with the Database 12 

APP Module 160, the SFP Module 132, and the FGIM ^ , ^ r.c-e m . y^- 

Module 164 to coordinate the integrated production-sales- 20 ^^^P^^^ aggregates/disaggregates 

inventory planning. This involves the evaluation of various ^ appropriate me forecasts to display at the chosen 

plan options, checking the consistency of the constituent ^, |iggregation eve . 

plans and resolving conflicts if needed. Check Forecast Errors , , k .h qpp 

Data Flow forecast error checking feature supported by the SFP 

TTie data flow diagram for the PSI Planning Frame 160 is 25 Module 132 computes and displays various n-period-ahead 

shown in FIG. 17. m PSI Planning Frame 160 generates ^^^^^^^^ erro^ of the botlotn-up and top^lown forecast, 

the Production^ales-Inventory Plan report 190 listed ear- Co°ipute and Display Related Stat^tics of Sales 

r pj^g g^igg Statistics compulation feature supported by the 

' Tlie Production-Sales-lnventory (PSI) Planning is a pro- ^f^."*^ .^^^ computes: mean and variance over a 

cess to reconcile demand and supply requirements in a 30 ^"eded time mterval, moving average, trend and/or sea- 

<• , • • _ . .u nci sonality factors 01 any chosen sales line and display result in 

supply chain. In the manufacturing environment, the PSI , ..v 

Planning Frame 160 helps to reconcile production, sales and several forms (graphical, tabular or both), 

inventory requirement discrepancies. In the repair ^orecass ^ 

environment, the requirements-supply reconciliation helps ^^^^^ ^"^"^^^^ ^^^^VJ^ ^^^'y^^/"/^"^^ 

to reconcile requirements and supply. 35 Management Frame 130 to check bottom-up forecasts from 

Manufacturing Supply Chain ^^'^^"5 ^^^^ vanous top-down forecast 

The PSI Planning Frame 160 supports the process that ""^'hods (e.g. moving average regression, combinations 

, , . . f 1 ^ 1 • ♦If etc.) rhe user then chooses the most appropnate set of 

develops an integrated production-sales-mventory plan tor a . ' , ^ , l j l • 

selected product group. The objective is to ensure that the bottom-up and top-down forecasts based on their accuracy, 

resulting PSI plan 190 meets customer requirements and 40 statistics and consistence with each other. 

.. c , . .... t • . I • . Reconcile Top-Down and Bottom-Up Forecasts 

satisfies supply capability constraints and the inventory ^ ^ ^ , ^ ^ ,,. . 

«u-^^-.,<. ^V,u^ „^ ru^ ^„™r,t Dci „Ur^ 1QA -.^ the process of top-down and bottom-up reconciliation 

obiective or the company, the current FSI plan ISO is . , . *^ . . f j 

,1 „„i»„=,i ..,„^.v,^, i DCI ion T^„ checks the discrepancy between the two forecasts and if 

displayed together with a temporary PSI plan 190. Ine , . n- • . r 

, oci ion ; f,^« ,Uf« necessary, resolves the conflicts between the two torecasts to 

temporary PSI plan 190 can be imported from vanous data . • , r r ,, - 
sources (including data series from Scenarios 78). The user 45 f""^*^ ^ more desirable sales forecast. The following 
can then analyze and modify the temporary PSI plan 190 ^^^^'^^^^^ P^^^''^'^^ to support ihis process: Compute the 
with easy reference to the current PSI plan 190. The user can difference between top-down and bottom-up forecasts; Gen- 
replace the current PSI plan 190 by the temporary one once "'^'^ ^^'Sh'ed average of top-down and boltorn-up fore- 
the latter has been improved to satisfaction. T^^'^T temporary sales (S ) line (see 

me PSI planning process requires the support of three 50 f^^'^^f ^'^"^^ ^i^]^^- ^dividual descnptions 

modules: the Sales Forecasting and Planning (SFT) Module '^^^ '^'^'^ ^'^'""'^^ 

132, the Aggregate Production Planning (APP) Module 162 Compute the difference between top-down and bottom-up 

and the Finished Goods Inventory Management (FGIM) forecasts. 

Module 164. The difference between top-down and bottom-up fore- 
Forecast Reconciliation 55 casts is computed and displayed to show the discrep- 

The Demand Management Frame 130 supplies Ihe Fore- ancy between the two forecasts, 

cast Data 146 (bottom-up and top-down forecasts) and an Generate weighted average of top-down and bottom-up 

indication of the methods used to generate them. 'ITie user forecasts. 

can use the same methods to generate new forecasts and/or The conflicts between the top-down and bottom-up fore- 
compare the forecasts generated by different methods. ITie 60 casts can be resolved by using a weighted average of them 
user analyzes and reconciles these forecasts to generate an to generate a new temporary sales forecast in the S' line, 
appropriate set of sales requirements. The PSI Reconcilia- Manually Overwrite Temporary Sales (S") Line 
tion 170, with the support of the SFP Module 132, revises The user manually overwrites the forecast on the S' line to 
forecasts and reconciles top-down and bottom-up forecasts. adjust the sales forecast to reflect various considerations of 
Revise Forecasts 65 influential factors. For example, adjust sales forecasts to 
'Die forecast revision process acquires., displays, analyzes account for unrecorded or anticipated upcoming market 
and edits Ihe bottom-up or top-down forecast. Ilie user first changes. 



10/21/2002, EAST Version: 1.03.0007 



6,151,582 

27 28 

Inventory Planning Determine Finished Goods Inventory Requirements 

The process of Inventory Planning supported by the The FGIM Module 164 based on the inventory policy and 

FGIM Module 164 and the Demand Management Frame policy parameters determines the finished goods inventory 

130 determines the finish goods inventory requirements. In requirements for the product groups. The user can then 

inventory planning, the user first selects a product group. To 5 modifies the inventory level requirements as appropriate, 

help the user 10 select an appropriate inventory policy, the The following features are identified for determining the 

DSS 10 computes and displays various sales measures finished goods inventory requirements: Compute and dis- 

which characterize the sales pattern of the chosen product play inventory level at chosen aggregation level; Manually 

group. For example, a Min-Max policy might be appropriate override inventory levels; and Compute and display inven- 

for a product group facing steady demand. The DSS 10 then, 10 '^^^^ ^' '^^"^^ aggregation level. , 

based on the inventory policy selected by the user and the PSI Piannmg Frame 160 supported by the FGIM 

managerial sales and service targets, determines the policy ^Jodule 164 computes the inventory levels based on the 

parameters and inventory level requirements. The user can ^^osen mventory policies and parameters^ TTie resuU will be 

\^ , r 1- . J • . 11 displayed in the temporary inventory (1) line. If the com- 

then modify the policy parameters and mventory leve ^ lower aggregation level than the chosen 

requirements to satisfy vanous managerial requirements and 15 ^. ^ oorrespS^ding appropriate aggregation 

production resources limitations. The followmg two features ^ ^^^^ ^^^^^^ ^-^^^^ 

are identified for this functional requiremem: Manually Override Inventory Uvels 

Formulate finished goods inventory policies; and The user can manually overwrite inventory levels to 

Determine finished goods inventory requirements. reflect various managerial concerns. For example, the 

Formulate Finished Goods Inventory Policies 20 unavailability of production resources at certain periods 

The formulation of finished goods inventory policies requires the decrease in corresponding inventory levels or 

involves the selection of inventory policies for chosen the suggested inventory level exceeds the given manage- 

product groups and specifying the corresponding policy ment target, 

parameters. It is broken down into the following features: Supply Requirement Planning 

Choose inventory policies for product groups; Choose 25 Thesupply requirement planning feature supported by the 

policy parameters; and Compute estimated inventory statis- APP Module 160 help determines the production require- 

tics. ments that are consistent with the sales plan and the inven- 

Individual descriptions of these three features are as tory requirements. It also checks the feasibility of the 

follows. production requirements with respect to production capacity 

Choose Inventory Policies for Product Groups 30 and key component availability. In case of infeasibility, the 

In this feature, the user select inventory policies for feature will provide information about the cause of corre- 

product groups based on the patterns of sales the product sponding infeasibility to the user. The user can then modifies 

groups are facing. It involves the following three steps: sales requirements, increases available resources 

Choose product group: The user specifies the product group (production capacity or key component availability) and/or 

(s) of interest; Acquire the following sales measures from 35 prioritizes the sales requirements and restricts attention to 

the Demand Management Frame 130: Usage rate — fast, satisfy a reduced set of high priority sales requirements only 

medium or slow moving, Lumpincss — sparsenessof signifi- in order to achieve feasibility, 

cant demands, and Volatility — coefficient of variation; and Determine Production Requirements to Sustain Sales 

Select inventory policy; The user chooses among the fol- The process of determining production requirements to 

lowing an inventory poHcy for the chosen product group(s) 40 sustain sales consists of the following two features: Generate 

based on the sales information acquired. production requirements; and Manually overwrite the pro- 

For single product group with non-lumpy demands: User- duction requirements. Individual descriptions of these two 

specified base-stock poUcy, Periodic review cost optimiza- features are as follows, 

tion policy, and Period review model with service level Generate Production Requirements 

constraints. 45 The production requirements generation feature sup- 

For related multiple product groups (e.g. groups sharing ported by the APP Module 160 determines the production 

the same production resources.) with non-lumpy demands: requirements based on sales and inventory requirements. 

Leveled Policy, Synchronized Policy, and Optimal Policy. There inventory requirements may take two different forms: 

For single product group with lumpy demand: Maximum Inventory levels, or Safely stocks. 

n-Period Coverage Policy. 50 In case of inventory level requirements, the production 

Choose Policy Parameters requirements are generated using the inventory balance 

The FGIM Module 164 based on the service level con- formula discussed herein, 

straints and managerial objective (e.g. minimize inventory In case of safety stock inventory requirements, the user 

carrying cost with a slock out probability of at most 5%) can choose one of the following objectives to determine the 

determines the policy parameters to be used for the inven* 55 production requirements: Minimize the maximum produc- 

tory policy chosen by the user. The user can then observe the tion capacity utilization; Minimize the maximum inventory 

results of the estimated inventory statistics and adjust the level; Minimize the total inventory level; and Minimize the 

policy parameters as appropriate. total inventory cost (inventory holding and backlog penalty 

Compute Estimated Inventory Statistics costs required). 

The estimated inventory statistics calculation feature sup- 60 The production requirements generated are displayed in 
ported by the FGIM Module 164 computes and displays the the temporary production (P) line. If result of sanity check 
following inventory related measurements: average inven- is at a lower aggregation level than the one chosen for 
tory level (as weeks of sales); expected stock-out probabil- dusplay, aggregation will be done before display, 
ity; service level (fill rate); inventory carrying cost; and total Manually Overwrite the Production Requirements 
cost (including production, inventory holding, stock out 65 ITie production requirements are modified to reflect van- 
penalty and transportation costs) for the chosen inventory ous considerations. For example, insufficient production 
policy and policy parameters. resources during certain periods. 
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Check Aggregate Production Capacity & Key ComponenI 
Availability 

In the process of checking the feasibility of sales, inven- 
tory and production requirements against the availability of 
production capacity and key components, the following 
features arc identified: Define key components; Check sanity 
of a given set of sales requirements (in S' line) and safety 
stock constraints; Check feasibility of production require- 
ments (in P line); and Update and display production 
capacity load and key component availability. Individual 
descriptions of these four features are as follows. 

Define key components. 

Each user defines a list of key components, which is 
recorded and can be modified whenever necessary. The lisl 
of aU components which arc sorted according to their 
availability/usage ratio is displayed to help the user to define 
or modify the list of key components. 

Check sanity of a given set of sales requirements (in S' 
line) and safety stock (in V line) constraints 

The process of sanity check utilizes the capacity checking 
model in the APP Module 160 to help determine the pro- 
duction requirements for the given set of the sales require- 
ments and safety stock constraints. Furthermore, the user 
can scope (he capacity checking model appropriately 
through modification of: Ljocation(s), Products or product 
groups, Time horizon. Production Unes, and Key compo- 
nents. 

If the results of the capacity model are infeasible, critical 
under-capacitated production resources and key components 
are suggested to (he user for further modifications. 

Check feasibility of production requirements (in P' line) 

This process checks sanity of a given set of production 
requirements against the production capacity and key com- 
ponent availability. This is also supported by the capacity 
checking model in the APP Module 160. Similar to the 
previous sanity check described above, the user chooses the 
appropriate scope of the capacity checking model and if it 
turns out to be infeasible, critical under-capacitated produc- 
tion resources and key components are suggested to the user 
for further modification. 

Update and display production capacity load and key 
component availability 

After a few iterations of the sanity checks and capacity 
requirement adjustment, the user can reach a feasible set of 
production requirements. The remaining available produc- 
tion capacity and key components arc updated and can be 
displayed if requested. The user can then accept or reject 
new production requirements based on the availability of 
production capacity and key components. 

Production-Sales-lnvcntory Plan Coordination 

The coordination of the production-sales-inventory plan 
ensures consistency among the production, sales and inven- 
tory plans and helps determine a feasible and appropriate 
PS I plan 190. 

Check and ensure consistency in PSl plan 

llie user can utilize this feature in either: Ihe independent 
mode or the consistent mode. 

In the former mode, the user can edil the production, sales 
and inventory requirements separately by disregarding any 
consistency requirement. In the latter mode, the DSS 10 
always ensures the consistency of the production, sales and 
inventory requirements. In the consisieni mode, (he follow- 
ing features are identified: Modify the plan according to the 
user defined sequence; Maintain the consLstency in other 
lines due lo the change of one line; Update the production 
(P), sales (S) and inventory (I) lines (see display figures 
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discussed herein) by their corre^onding temporary lines; 
Maintain consistency at different aggregation level (for 
either the consistent or independent modes only). Individual 
descriptions of these feamres are as follows. 
5 Modify the plan according to the user defined sequence 

When the user first switches to the consistent mode, two 
of the temporary production, sales and inventory lines have 
lo be selected to generate the third line using the inventory 
balance formula discussed herein. 

Maintain the consistency in other lines due to the change 
of one line 

Whenever a temporary production, sales or inventory line 
is overwritten, it will be modified together with one of the 
remaining two lines (pre-selccted and can be re-selected 
anytime by the user) to maintain consistency. 

Update the production (P), sales (S) and inventory (1) 
lines by their corresponding temporary lines 

The user can replace the set of P, S and I display lines (see 
display discussion herein) by a set of consistent P', S' and I' 
lines. The P, S and I lines can always be saved as a scenario. 
Only user with the appropriate system privilege can save the 
P, S and I lines lo the DSS Database 12 permanently. 

Maintain consistency at dififerent aggregation level 
25 The DSS 10 can display data at any resolution higher than 
the primary data resolution level. Whenever display at a 
higher resolution is modified, disaggregation will be done to 
maintain consistency. The DSS 10 computes a set of default 
disaggregation logic based on existing lowest resolution 
data. The user can overwrite the disaggregation logic when- 
ever appropriate. 

Evaluate PSl plan options 

llie PS! plan options evaluation feature computes and 
displays the performance metrics for various versions of the 

35 PSl plan 190 for the user to compare and choose a desirable 
one. The following two features are identified to support this 
feature: Compute relevant performance metrics; and Com- 
pare different plans. Individual descriptions of these two 
features arc as follows. 

40 Compute relevant performance metrics 

The following performance metrics are computed using 
the routines specified in the SFP 132, FGIM 164 and APP 
Module 160 to assist the user to select a more desirable 
version of the PSl plan 190: Total and breakdown of costs, 

45 Average inventory level, Average expected stock-outs. 
Expected Throughput Time, and Expected Service level. 
Compare different plans 

Different PSl plans 190 over the same or different lime 
periods together with their corresponding performance met- 
50 rics arc displayed side by side for comparison purposes. 
Repair Environment 

In the Repair Environment the term "Requirements- 
Supply Reconciliation" is used in place of Production-Sales- 
Inventory planning. This reflects the fact thai there is no 

55 production nor sales in a repair environment but "repair 
requirements" and "repair supply" in the form of repair 
workstation capacity and component availability. 
"Requirements-Supply Reconciliation" Planning is a recon- 
ciliation process that develops an integrated and feasible 

60 plan. 

The Requirements-Supply Reconciliation comprises of 
two main processes: Estimation of the aggregate repair 
requirements based on the inventory position of serviceable 
parts at the repair location and the target level for this 
65 inventory; and Feasibility assessment for the aggregate 
repair requirements under resource capacity (skills and 
workstations) and component availability constraints. To 
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support these processes the following functional require- 
ments have been defined. 

Evaluate and propose Consolidated Serviceable Inventory 
(CSl) Levels based on past usage and future usage require- 
ments. 

The following operations are performed: Refine variabil- 
ity and lumpiness estimates of usage; Refine repair lead lime 
estimates; and Propose target CSl levels. 
Determine Aggregate Repair Requirements 

This includes using target CSl levels, and current inven- 
tory positions to determine aggregate repair requirements. 
Generate Aggregate Repair Plan 

This includes the foHowing: Verify repair resource capaci- 
ties to satisfy aggregate repair requirements based on; repair 
personnel skill sets; workstations features; Verify key com- 
ponent availability to satisfy aggregate repair requirements; 
and Generate aggregate repair plan under capacity and 
component constraints. 
Supply Management 

The Supply Management Frame 200 supports the Supply 
Management decision process. 
Module and Data Space Association 

FIG. 18 shows the participating modules and the associ- 
ated data spaces for this Frame 200. 
Process Flow 

The process flow diagram for the supply planning frame 
200 is shown in FIG. 19. The Supply Management Frame 
200 supports the following functional requirements identi- 
fied for the Supply Management decision process: 
Aggregate Production Planning 

The APP Module 160 works closely with the FGIM 
Module 164 and uses Inventory Data 182 and the Production 
Capacity Data 180 to evaluate production and inventory 
trade-offs. The APP Module 160 also uses the Production 
Requirements Data 174 from the PSI Planning Frame 160 to 
generate aggregate production plans. These are written to the 
Aggregate Production Plan Data 202. 
Dynamic Rcplanning 

The aggregate production plan is often modified by the 
APP Module 160 to reflect either changing production 
requirements provided by the PSI Planning Frame 160 
through the Production Requirements Data 174 or changing 
component availability from the Material Planning activity 
210 through Material Delivery Schedule 212. 
Capacity Planning 

The APP Module 160 utilizes long-term Production 
Capacity Data 180 from the Product Planning activity 214, 
the production parameters such as process times from Pro- 
duction Matrix 216, and the planning bill-of-material for the 
product from Planning BOM 218 to determine the produc- 
tion capacity requirements. In so doing, the APP Module 160 
may evaluate a number of production capacity options such 
as various production line structures and allocation of 
resources. The capacity plan is written to Production Capac- 
ity Data 180. 

Component Procurement Policy Development 

The Component Procurement Policy Development 
(CPPD) Module 230 reviews the long-term component 
requirements in Component Requirement Data 232 and 
other relevant component supply information to formulate 
component procurement policies. The component procure- 
ment policy parameters arc then written to Component 
Supply Contract 234. 
Data Flow 

The data flow diagrams for the Supply Management 
Frame 200 are shown in FIG. 20 and FIG. 21. 'Ilie Supply 
Management Frame 200 generates the core report previously 
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discussed, namely, the Master Production Plan 240 and the 
Production Capacity Plan 242, 
Vendor Managed Replenishment Frame 

The Vendor Managed Replenishment (VMR) Frame 250 
supports the VMR decision process. 
Module and Data Space Association 

The Data Space associations for Frame 250 are illustrated 
in FIG. 22. 
Process Flow 

The process flow diagram for the VMR Frame 250 is 
shown in FIG. 23. The VMR Frame 250 supports the 
functional requirements identified for the VMR decision 
process: 

VMR Strategic Planning 

The VMR Strategic Planning activity 252 in concert with 
the MDA Module 134 and the FGIM Module 164 considers 
the financial and business requirements supplied by the 
customers, distribution infrastructure, POS history and the 
transportation factors in the Supply Chain Network data 
table 260 to evaluate various service contract options. The 
VMR contract parameters are then written to VMR Contract 
262. 

Replenishment Planning 

The Replenishment Planning activity 270 working with 
the MDA 134 and the SFP Module 132 reviews the sell- 
through information and provides input to the FGIM Module 
164 to generate the corresponding replenishment require- 
ments. These requirements are refined according to the 
VMR Contract 262. Based on these inventory requirements, 
the VMR Contract 262 and the order fulfillment activity, the 
replenishment schedule is generated and written to VMR 
Data 272. 
Data Flow 

The data flow diagram for the VMR Frame 250 is shown 
in FIG. 24. The VMR Frame 250 generates the Replenish- 
ment Schedule report 280 listed eariier. 

VMR, also referred to as direct replenishment, is a 
growing agile logistics partnership agreement where the 
vendor takes on the responsibility of managing the inventory 
at the customer sites for the products it supplies, i.e., 
monitoring, planning, and directly replenishing the inven- 
tory in the customer's distribution network. In other words, 
under a VMR arrangement, it is the vendor who determines 
when stocks are to be replenished and in what quantities, 
rather than responding passively to orders placed by the 
retailer. This arrangement is usually typified by a contract 
which specifies the financial terms, inventory constraints, 
and performance targets such as service measures. VMR is 
almost invariably based on the availability of direct access 
to point-of-sale data and the customer's inventory positions. 
Such an arrangement can be mutually advantageous to the 
customer and the supplier. 

On the other hand, VMR requires the integration of 
inventory and transportation planning processes of the sup- 
55 plier and the customer. Although much has been written in 
the general literature about VMR as a concept (e.g., Wal- 
Mart's relationships with its suppliers) there are few known 
quantitative models, if any, to support VMR. Existing VMR 
systems are transaction oriented and provide little or no 
60 decision support capabilities. 

The VMR Frame 250 consists of a set of decision support 
tools that can be used in the development of VMR programs. 
'ITie features offered by the VMR Frame 250 support the 
decision making processes in the VMR programs at both 
65 strategic and operational levels. More specifically, at the 
strategic level, the user can invoke the features provided by 
the Frame 250 to study of the feasibility of VMR programs; 
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evaluate the terms of VMR contracts; and periodically Repleoishmeat Orders (Receipts, In-transit, Incjompleie, 

review the overall performanOT of the VMR program. etc.): The detailed order status infamiation that is 

At the operational level, the user can invoke the Frame recorded to capture the replenishment activities 

features to develop sell-through forecasts; obtain suggested included in the program. 

replenishment quantities; revise replenishment quantities; 5 Maximum and Average Inventory Levels: The targeted 

and monitor sales and other VMR related statistics. maximum and average inventory levels specified in the 

In this section, we will provide the functional spccifica- VMR contract. They can be used to monitor the current 

tion for the VMR Frame 250. The entire Frame 250 can be performance of the VMR program, 

partitioned into three main pans: basic and VMR specific Service Lxvcis: 'Ilic targeted customer service levels 

data maintenance, strategic planning and replenishment specified in the VMR contract. 

planning U supports the following two functional require- DeUvery Frequency: The delivery frequency is defined by 

ments: VMR Strategic Pbnmng: Evaluate financial and ^^^^ ^j^^ ^ ^^^^ frequency at 

log^tical tradeoflfs m a VMR contract, and Coniparatwe ^^^.^^ /^^^ replenished for a particular 

analysis 01 vanous service contract options; and Replenish- ^ 
mcnt Planning: Review sell-through and determine inven- 
tory requirements at retailer's location, and Formulate the i5 Promotion Calendar: The calendar captures the relevant 

replenishment plan. promotion activities. This information is then used to 

The main decision modules to support the VMR Frame ensure that a sufficient additional amount is included in 

250 include MDA 134, SFP 132, VMR and APP 160. We the regular replenishment quantity, 

will discuss the functional specifications that are applicable Strategic Planning 

to the manufacturing environment. 20 Strategic planning features mainly support VMR deci- 

Data Maintenance sions during the initial program setup; important during 

To support general functionality of the VMR Frame 250, VMR contract negotiation stages. They are also useful to 

the system should maintain two types of data: the Basic provide critical operating parameters, e.g., replenishment 

Structural Data and the Replenishment Data. In the follow- frequencies. Finally, they are also needed to conduct long- 
ing two sub-sections we discuss the details of these two sets 25 term performance reviews. Therefore, the functions pro- 

vided at the strategic level arc addressing the issues which 

Basic Strxictural Data arc of long-term importance, even though these decisions are 

These include the essential data elements required to ^^^^ ^ frequently. 

describe the basic characteristics of the products, distribu- i/.^d c»t..„ 

™ . ^ . f ■ . Li J VMK Contract ^etup 

Don network, etc. This set of data are relatively stable and n. ■ .u • 1 * <^ , 1 \n,Ao 
, '. , , - . .u ■ L 30 Dunne the initial stage of potential engagement in a VMR 

require only infrequent updates (e.g., at the time when the " . j- ■ Z im^r, . . a 

\7wn • u ■ --.-i-^ u ^1 program, the conditions m the VMR contract are proposed, 

VMR program IS being initialized, or when new models are ... . - . , . • / 

being added to the program). Tliesc include: ^^''^^ negotiated. Under such circumstances, the user 

Distribution Network: Define the customer as well as the evaluate the costs and benefits of many different 

vendor's product distribution networks that are relevant P^'^S^'" «P^'°"^- ^^en the terms are conflicting, tradeoffs 

to the VMR program. It identifies which product is have to be made. In addition, one also has to choose a set of 

being distributed from which vendor warehouse and operating parameters and procedures which optimize total 

which customer Distribution Center (or store) are ^ost measures while satisfymg given constraints. The fea- 

assigned to each warehouse. provided below are to support these decision making 

Distribution Center (DC) Profile: Define the main problems. a 
attributes of a customer DC or a vendor warehouse ^ , .^^^ ^ product/product group a customer DC, and a 

including its location (city and state) information. ^^^'""^{y frequency defined by the user, the system wUI 

,^ ^ ■ , . • r L J- L • provide the computed relationship between expected service 

Uad-times: Define the lead-time for product distnbution j;^^, maximum (average) inventory level. Such a rela- 

between a given pair of locations and the corresponding ^^^^^^ ^j^, be useful for the user to evaluate what-if 

transportation modes. Scenarios and can be used in other features in this Frame 

Transportation Costs: Define the transportation costs for ^^^ ^ Replenishment Planning below). 

product distribution for given transportation modes. Compute and dbplay expected service level for the maxi- 

Product Profile: Define the mam attnbutes of the products j^um inventory requirement defined by the user, 

participating in the VMR program including their IDs Estimate and display the proper inventory level for a 

and physical characteristics. It also specifies whether a ^^^^^ service level defined by the user, 

product is currently in the VMR program. ^hen evaluating the optimal VMR operating parameters 

Product Replacement Relationship: Define the relation- or conditions in the contract, the system can help the user to 

ship between a current product and its predecessor either check the compatibility of a set of constraints includ- 

(being replaced). This provides the basic information to jng service level, inventory level and delivery frequency, or 
establish a continuous demand stream for a pair of 55 select an optimal set of these parameters after the evaluation 

closely related products. of all feasible combinations. 

Replenishment Data 'jo use this feature, the user first needs to choose the 

Replenishment data are more dynamic, and record the product/product group and the DC of interest, 

details about the replenishment activities as well as the For a given replenishment scenario (a given set of deliv- 
characteristics of the VMR program itself. These include: 50 cry frequency, target inventory level and customer service 

l*roduct and DC Watch List: A set of products and DCs level), the system will estimate the total cost including 

that are defined by the user to be monitored by the customer DC inventory carrying cost, transportation cost 

system so that any special movements or activities can and manufacturing plant inventory carrying cost, 

be detected and reported. Different replenishment Scenarios can be generated based 
Seasonality Factors: The set of factors calculated by the 65 on diflerent values of delivery frequency, target average 

system or provided by the user to characteri/c the basic inventory level and target customer service level. In order to 

seasonal fluctuation patterns in the sales activities. compare these differcnl options without using total projected 
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costs like Ihe one suggested in the feature above, the system 
will compute key statistics such as expected inventory levels 
at customer DCs and manufacturii^ plants. By comparing 
these statistics, a better replenishment scenario can be iden- 
tified. 

Contract Parameter Monitoring and VMR Program Review 
After a VMR program has been setup and the execution 
started, it requires constant monitoring of the key policy 
parameters and performance measures. If there are substan- 



that end, the system allows the user to develop and examine 
not only the replenishment quantity of the next replenish- 
ment cycle but also to extend several periods ahead so that 
these longer term forecasts can also be estimated and used 
for other (e.g., manufacturing) planning purposes. 

Based on the sell-through data provided by the customer 
for a given product/product group at a customer DC, the 
system will generate sell-through forecasts including mean 
and standard deviation for any given product at a customer 



lial changes, it is critical to report them back to the users, to DC. The actual forecast algorithm will invoke an appropriate 

ITiis is because the optimal operating parameters in the one specified in the SFP Module 132 which should consider 

VMR program set at the strategic level are obtained under trend, and seasonality among other basic aspects of the data 

certain assumptions about these key indicators. In addition, stream. In case of a product having too little sell-through 

periodically, the management will be interested in the actual history, the system will use the product replacement rela- 

cflFectiveoess of the VMR program. To support such program 15 tionship defined to establish more continuous sell-through 

reviews, the system will rccoixi and generate management history. In addition, the system will also permit the user to 

reports regarding the actual performance of the VMR pro- select an appropriate length of historical data to account for 

gram compared to the inventory and customer service level abnormal sales activities for the product, 

targets set in the VMR contract. '^h^ system will also generate longer terni replenishment 

Periodically (which can be defined by the user), the 20 requirements for the demand orientation for a given product 



system will compute the mean and standard deviation of the 
sell-through for a given product of a given customer DC. 
'ITie resulting numbers can then be compared to the histori- 
cal norm defined by the user, the quantitative modeling 
assumptions, or recorded by the system. If the mean and 25 
standard deviation are outside of the defined range, then the 
user has to be informed through a product sales exception 
report or other similar reports. The user will be asked to 
define the following: Frequency of such evaluation; Histori- 
cal norm of the mean and standard deviation; and The ranges 50 
of the mean and standard deviation. 

One of the key objectives of any VMR program is to 
reduce the total inventory levels at different parts of the 



so that the user can plan for the longer term demands for the 
product. To generate medium to long term forecasts, the 
system will first forecast the sell-through for the specified 
time periods by invoking appropriate forecasting algorithms 
in the SFP Module 132. Then, a set of replenishment 
quantities will be generated using the replenishment algo- 
rithm in the VMR module. These replenishment quantities 
will then become the demand forecasts for the product. 
Replenishment Order Generation 

The generation of replenishment orders is the main func- 
tionality of the replenishment planning of the VMR Frame 
250. The main objective of the functionality is to provide the 
user with an initial set of replenishment quantities for a set 
of products with the consideration of the sell-througb fore- 



supply chain. The system will compute and record average 

inventory levels and compare it to maximum and average 35 casts as well as VMR specific operating parameters. The 

inventory targets. The results can then be reported to the user quantities will then be approved by the user and converted 

as requested. actual purchase orders. 

When the inventory level of a given product/product Based on the forecasts of the future sell-through, user 

group at a customer DC is much higher than needed, part of defined VMR operating parameters (e.g., customer service 

the inventory should be considered as excess. The system 40 level, maximum inventory level and delivery frequency), 

will report the list of products whose inventories are in and other related indicators (e.g., last reported customer DC 

excess. These products then wiU be off the replenishment inventory level), the system will generate a suggested 

product list untU the inventory leveLs return to a normal replenishment quantity for a future replenishment date, 

range. During these periods, the produaion and many other If 'he product model year changes are regular, then it is 

logistics operations planning will have to be notified about 45 necessary to treat the replenishment quantity needed for 



the reduction in planned quantities. 
Replenishment Planning 

This is to support more operational decision problems on 
a regular basis after the VMR program has started its 
execution. During this stage, the main concerns of the user 50 
will be shifted to those of a more operational flavor such as 
the generation and revision of the replenishment order to 
satisfy target customer service levels and maximum inven- 
tory constraints. In addition, in order to ensure the validity 
of the decision support models and prepare the decision 55 
makers for changes in the markel place, the system will 
monitor certain operational indicators relating to the VMR 
program. The indicators and purpose of this monitoring are 
distinctively different from the monitoring and review func- 
tion offered at the strategic level. 60 
Sell-'lTirough and Demand Orieniation Forecasts 

Before we can start to use the system to generate replen- 
ishment orders, a set of .sell-through forecasts have to be 
developed. We will use Ihe models developed in SFP 132 
using POS as the primary data source. On the other hand, the 65 
production planner at the manufacturing vendor needs to 
know longer term forecasts to plan for future capacities. To 



product (or VMR program) initialization and termination 
differently from the regular replenishments. Therefore, the 
above feature has to be modified to be applicable to these 
settings; 

Set Initial Replenishment Quantities: The main difference 
between the initial replenishment quantity setup and the 
regular one is that it may require additional quantities 
to fill customer DCs or stores. In addition, because 
there is no sell-through history available for these new 
products, the history for the replaced products will have 
10 be used in the computation. It is also necessary to set 
a time frame for the computation algorithm to use a 
new product's data when il accumulates enough data of 
its own. 

Balance-out at the End of a Season: At the end of a selhng 
season, a product needs to be phased out. In such a 
situation, the system will not generate any further 
replenishment quant ilies for the product unless the user 
decide to overwrite the suggested (zero) quantities for 
a special reason. 

For a given customer DC, when the products are being 
considered for replenishment, the system will help the user 
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set joint replenishment orders so thai the total cost for the replenishraenl activities as well as the methods used to 

replenishment batch can be minimized. The basic logic is to generate recommended replenishment quantities. Therefore, 

add or delete products included in a replenishment batch to the system will provide the raoniloiing and tracking capa- 

optimally use the transportation means while maintaining bilities for the user to better manage the sales changes. In 

satisfactory customer service level and inventory level. 5 addition, the operating parameters specified in the contract 

The system will also automate the replenishment quantity ^iso be monitored so that the user can be reminded 

generation for a set of products selected by the user. This whenever the replenishment quantities arc likely to exceed 

feature is useful especially when the number of products in q^^. ,^^^^3 ^^^^ contract. 

the VMR program is relatively large and the user prefers to J^^^ ^ ^ ^^ ^^-^y^-^ the historical 

work only on exceptional issues rather than examimng the Qormsofmean and standard deviation ofselMhrough so that 

details of each product s replenishment activities. ^ ^^.^^^ j^j^ 

Replenishment Order Revision ■' j ■ • j- . ^ u. . 1 1 u 

After the initial replenishment quantity has been gener- P^"^^^- ' ^ an indicator of substantial sales changes 

ated for each product, the user may be interested in exam- the recent sales deviate from the user specified ranges of 

ining the entire or only a selected set of products to make historical norms. 

sure that the soft information can be reflected in the actual 15 'llie system will monitor whether the suggested replen- 

repleoishment orders. In addition, a number of constraints ishment quantity is gomg to exceed the maximum mvenlory 

such as product availability and production capacity will level allowed in the VMR contract. The user will then be 

also have to be taken into consideration. The objective of the notified to take further action. 

features listed below is to help the user revise the replen- On a regular basis, the system will record a set of tracking 

ishment orders with relevant analysis and search support 20 signals and compute forecast errors so that when substantial 

tools. changes occur, it should be reported back to the user to take 

The user can define a set of exceptional report generation further action, 

criteria so that the system can search for and display the Distribution Network Design 

products falling into the range. The sample user-defined The Distribution Network Design Frame 290 supports the 

criteria will include 25 Distribution Network Design. 

Mean and standard deviation exceeding certain limits of Module and Data Space Association 

the historical norm FIG. 25 shows the participating modules and the associ- 

The customer DC inventory exceeding the maximum ated data spaces for (his frame, 

inventory level after the suggested replenishment quan- Process Flow 

tity arrives 30 The process flow diagram for the Distribution Network 

For a given replenishment quantity (either recommended Design Frame 290 is shown in FIG. 26. The Distribution 

by the system or input by the user), the system will estimate Network Design Frame 290 supports the functional require- 

and display the probability of stock-outs. To compute the ments identified for the Distribution Network Design deci- 

probability value, a search algorithm is needed in addition to sion process: 

the relationship between inventory quantity, customer ser- 35 1. Distribution Location Analysis 

vice level and delivery frequency. The user can use the The Finished Goods Network Design (FGDND) Module 

feature to evaluate whether the replenishment quantity sug- 292 works with the MDA Module 134 and the SFP Module 

gestcd is satisfactory or not. 132 to develop a forecast of aggregate long-term demand 

Most of the replenishment quantities discussed here are which is then used to evaluate potential Distribution Center 

appropriate for non-promotional sales. When a promotion 40 (DC) locations. The chosen DC locations are then written to 

for a product is planned, the user should be informed so that Inventory Node 294. 

the final replenishment quantities can incorporate additional 2. Distribution Network Optimization 

quantities due to the promotion. The objective of this feature The FGDND Module 292 works in concert with the 

is to identify promotion events during a given replenishment FGIM Module 164 to optimize the overall network configu- 

review period and help the user incorporate additional 45 ration. The result of this optimization is the assignment of 

quantity for the events. demand nodes to DCs and the assi^ment of production 

Before the replenishment orders can be finalized, the DSS nodes to DCs. 'ITiis information is then v^ritten to Supply 

10 will make sure that the vendor can supply the required Chain Network 296. 

quantities in the specified time frame. If the replenishment Data Flow 

order shipment date is close to the review date, then the 50 The data flow diagram for the Distribution Network 

product (finished goods) availability will be checked; and if Design Frame 290 is shown in FIG. 27. ITie Distribution 

the shipment date is further into the future, then the pro- Network Design Frame 290 generates two of the core 

duction capacity will be examined. reports Usted earlier, namely, the Customer-DC Assignment 

In order to properly make tradeoffs between different 300 and the Supply-DC Assignment 302. 

replenishment Scenarios, the system will estimate the total 5S Model Engine and the Modules 

cost (including the inventory and transportation among In this subsection, the overall design of the Model Engine 

others) for a given set of replenishment quantities. 'Vhc cost 20 is introduced. The objective, scope, and features of the 

will be computed automatically as the user is making seven constituent modules of the Model Engine 20 are 

modifications in the replenishment orders. discussed. 

lb reduce the transportation cost, a rough-cut tnickload 60 The Model Engine 20 consists of a library of specialized 

planning toot will be provided to the user so that the room quantitative models and analysis routines. To address the 

left on a truck can be filled by other most-needed products needs of a set of users, a Decision Support Frame calls and 

for the same customer DC. llie underlying logic is to build assembles these models and analysis routines with the 

a tmckload of shipment whenever it is possible. appropriate data. 

Sales Activity Monitoring and Replenishment Review 65 The number of models and analysis routines within the 

The movement of product sales reflected in the sell- Model Engine 20 could be quite large by virtue of the 

through data will have different impacts on the future modular design and inherent complexity of the DSS 10. To 
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better manage ihe Model Engine 20, there is a need for 
logically grouping the models and analysis routines. 
Furthermore, these models and analysis routines support 
tnajor decision-making areas in a supply chain. Therefore, 
the models and analysis routines are grouped into seven 
modules corresponding to the principal decision-making 
areas in the supply chain as shown in FIG. 28: Market Data 
Analysis (MDA) 134; Sales Forecasting & Planning (SFP) 
132; Vendor Managed Replenishment (VMR) 252; Finished 
Goods Inventory Management (FGIM) 164; Aggregate Pro- 
duction Planning (APP) 162; Component Procurement & 
Policy Development (CPPD) 230; Finished Goods Distri- 
bution Network Design (FGDND) 292; A frame by virtue of 
its definition may require the participation of some subset of 
modules (i.e., the models and analysis routines of these 
modules will be involved). In the case of the PSI Planning 
Frame 160, the MDA 134, SFP 132, FGIM 164, and APP 
160 Modules will be involved in constituting the decision 
logic 76. 

In many cases, the same models and analysis routines may 
be employed by distinct frames in different contexts, where 
the relationships between the models and the associated data 
linkages vary accordingly. This requires that the Supply 
Chain Frame Manager 24 interact directly with the models 
and analysis routines in the Model Engine 20. The models 
and analysis routines will therefore have standard data and 
logic input/output (I/O) formats. The standard 1/0 formats 
will also facilitate the maintenance of the individual models 
and analysis routines, e.g., updating and replacement. 

In addition to the seven modules defined above, there is 
also a group of general purpose numerical routines that are 
not specific to any of the above seven modules. These 
routines are collected into a design element referred to as the 
Model Engine Utilities 22, as shown in FIG. 1. Examples of 
the Model Engine Utilities 22 include generic linear pro- 
gramming solvers, and statistical analysis routines. 

Table 7 lists the modules in Ihe DSS architecture for the 
two supply chains. 

TABLE 7 

Modules m the Manutactuiing and Equipment 
Repair Supply Chain 



Manufacluring Supply 


Equipment Rqiair Supply 


Chain 


Chain 


Market Data Analysis 


Market Data Analyets 


(MDA) 


(MDA) 


Sales Forecasting & 


Sales Forecasting & 


Planning (SFP) 


Planning (SFP) 


Finished Goodi 


Innbhcd Goods Inventory 


Inventory Management 


Management (FGIM) 


(!-GIM) 




Aggregate Production 


Aggregate Production 


Planning (APP) 


Planning (APP) 


Component Procurement & 


Component Procurement & 


Policy Dcvelopmeni 


Policy Development (CPPD) 


(CPPD) 




Vendor Managed 




Replcnbhmenl (VMR) 




Finished Goods 




Distritnition Network 




Design (FGDND) 





Forecasting, Sales Promotion Analysis and Vendor Managed 
Replenishment. The models and the routines in this module 
are used to: Analyze relevant industry data from various 
sources; and Provide quantitative analyses of sales. 
5 Scope and Objective 

Objective: Compile and synthesize hybrid sources of 
market information for the purpose of sales forecasting and 
planning, and VMR. 

Scope: Industry-wide, company specific and point-of-sale 
data. 

Features: Analyze relevant industry data from sources 
such as Nielsen and EIA (Electronics Industry Association); 
Develop customer and customer/product profiles; Maintain 
15 promotion calendais of major customer and the enterprise; 
analyze promotional effects; and Provide quantitative analy- 
ses of sales at retail ouilets whenever point-of-sale data are 
available. 

Demand Characterization 
20 The models and routines in tbe MDA 134 module to 
support demand characterization in the Doramcrcial setting 
are equally applicable to support requirements characteriza- 
tion in the defense setting. 

For national defense applications, the actual repair item 
usage data conrespond to the POS Data 138 in the commer- 
cial setting. Analysis for POS Data 138 can be performed on 
the repair item usage data to characterize demand for various 
parts. Furthermore, in order to intuitively access relevant 
repair item-related data and information, the relationship 
among different parts has to be established. To thai end, we 
will develop a tree structure to represent the bill of material 
where each node of the tree corresponds to a repair item, and 
each arc represents a parent-child relationship. For ease of 
presentation we employ commercial nomenclature in the 
following section. 

Analysis Routines for Demand Characterization 

In the following, we describe three types of analyses that 
will be performed on industry survey data. Demand History 
40 Data 136, aixl Point-Of-Sales Data 138 to characterize the 
demand for the products (or services in defense 
applications). There arc other types of analysis that can be 
performed on these data sets which will be discussed sepa- 
rately when each individual data set is being considered. 
45 Product Family Composition Trend and Percentage 

This involves the analysis of the trends in quantity and 
percentage of each product family over a given period of 
time of the lime series. The input of the analysis routine is 
the set of time series corresponding to the product families 
50 and the associated product family names. 'Die output is the 
trend of the quantity, and composition percentage for each 
individual product family. For example, Table 5 below 
provides the percentage changes for major color television 
product families (13"-14\ I5"-24", 25", 26" and 27" & 
55 above televisions) from 1988 to 1994. 

TABLE 8 

Sample Product Family Composition Change from 198S- 
1994 



25 
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Market Data Analysts (MDA) 134 

The MDA Module 134 contains quantitative models and 
computational routines that compile and synthesize hybrid 
sources of market information to support Sales Forecasting 
& Planning, and VMR. 'ITie models and routines of the MDA 
Module 134 are used in support of Demand 
Characterization, Bottom-up Forecasting, Top-down 
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13--14- 


15'-24- 


25" 


26' 


27-4 


1988 


24.76% 


55.87% 


6.05% 


7.14% 


6.18% 


19S9 


24.98% 


54.86% 


7.28% 


5.01% 


7.87% 


1990 


22A2% 


54.79% 


8.06% 


4.56% 


10.47% 


1991 




49.5J% 


10.53% 


3.90% 


li96% 


1992 


7D.62% 


48.18% 


13.29% 


3.40% 


14.51% 
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TABLE 8-continued 




Sample Product Family Composition Change from 198S- 
1994 


]3"-14- 15--24- 25" 


26' 27-+ 


1993 19.13% 45.12% 15.87% 

1994 18.57% 41.58% 17.58% 


2.10% 17.78% 
1.55% 20.71% 
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Pareto Analysis of Sales 

The analysis involves the plotting of the percentage 
cumulative sates levels vs. the percentage of total number of 
products to determine the ABC classification of each product 
as illustrated in FIG. 29. 
Objective 

To identify the products or customer that contribute the 
most to the overall sales or production volume. To establish 
the ABC classification of products (or customers). 
Input 

POS Data 138, Shipment or production data. 
Output 

Plot of the cumulative percentage sales (or production) 
levels vs. the percentage of total number of products or 
customer generating this sales (see FIG. 29) 
Algorithmic Steps 

Rank products or (customers) in decreasing order of sales. 

Starting from the top of the list compute: 
cumulative sales 

cumulative number of product (or customers) 

Plot percentage of cumulative sales as a function of 
percentage of total number of products (or customers). 

In addition, another scatter plot can be drawn to show the 
volatility vs. sales (where measure of the volatility is the 
coefficient of variation) as shown in FIG. 30. Each point in 
the second plot corresponds to a product (or product family), 
and the result of these two plots can be used to develop 
differentiated inventory control policies for products with 
different demand patterns. 
Correlation Analysis Among Product Families 

'ITiis involves the analysis of the correlation among the 
lime series corresponding to different product families. The 
input of the analysis routine is the set of time series 
corresponding to the product families and the associated 
product family names. The output is the correlation coelE- 
cient for related product families. 
Industry Survey (ElA) Data 

Electronics Industry Association (EIA) collects manufac- 
turer to retailer Demand History Data 136 monthly from all 
major consumer electronics manufacturers. After consolida- 
tion by EIA, the data are sent back to the manufacturers for 
(heir own usage in analyzing industry wide sell-in activities. 
The data may be obscured by temporary slocking and other 
short-term dealings between individual manufacturers and 
retailers, and they are usually a few months late. 'ITiereforc, 
the data are oormally not suitable for short term demand 
characterization and forecasting. However, for longer term, 
the data arc useful in revealing trends and changes in the 
sales of overall and individual product families. The three 
types of analyses described herein can be performed on the 
EIA data to monitor the long-terra demand level and com- 
position changes. 
Demand History Data 

Not all retailers are capable of collecting and providing 
the POS Data 138 to iheir manufacturer suppliers. For this 
reason, marc tradilionni Demand History Daia 136 should 
be analyzed to characterize the demand for ihe manufactur- 
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er's products. We realize that the demand data are a reflec- 
tion of Ihe customer demand but they can be altered by a 
number of factors. For instance, meeting the quarter-end 
sales target or taking advantage of temporary sales promo- 
tion deals may make true consumer demand for the products 
less apparent. Nevertheless, the Demand History Data 136 
are an important source of demand information that can 
complement the short term demand information from the 
analysis of POS Data 138 and the long terra demand 
information obtained from EIA data. In general, Demand 
History Data 136 are more suitable to analyze the medium 
term sales level and trend information. The three analysis 
routines described herein can be applied to the Demand 
History Data 136 to derive the medium terra sales level and 
trend change information. 
Point-of-Salcs (POS) Data 

Major retailers are now collecting the sales transaction 
data from the scanners at the sales counter and sending the 
data to their manufacturer suppliers after summarization. 
The data directly reflect the consumer demand for the 
manufacturer's products and response to sales promotions. 
They can serve as signals to the changes in sales trend and 
consumer reactions to marketing efforts. In essence, the POS 
Data 138 can be used to detect short term sales levels and 
their changes for the manufacturer's products at various 
retailing outlets. The three types of analyses described 
herein can be pcrfomied on the POS Data 138 to monitor the 
short term demand levels and their ongoing changes. 

The inventory status represented in the POS should be 
verified in order to be used to assess the supply chain 
finished goods inventory situation. Shipment quantities from 
the manufacturer to the retailer are determined by consumer 
demand, and retailer's inventory carrying policies, among 
other influential factors while the POS Data 138 are much 
more direct in reflecting the true consumer demand. The 
following three analysis routines will be applied to POS 
Data 138 in addition to the three general ones mentioned 
herein. 

Inventory Status Verification 

To verify the inventory status, the POS Data 138 can be 
used in combination with the shipment data, and the inven- 
tory balance equation to compute the deduced inventory 
status. Then, the deduced inventory status can be compared 
to the reported inventory status. 
Inventory Profile 

The inventory profile corresponds usually to the manage- 
ment decision of an organization, and can be used to judge 
the over- and under-stocking situation along the supply 
chain. The normal inventory profile for each product and 
customer combination will be captured and stored so that it 
can be later retrieved and compared to the current and future 
(projected) inventory profiles to determine the possible over- 
and under-slocking situations. 
Detection of the Changes in POS Data 

The normal sales levels and associated variance intervals 
can be either calculated from the POS Data 138 for a given 
product by a customer, or specified by a user who is 
knowledgeable about the sales activities for the product. 
When the sales level fluctuates beyond the normal sales 
variance intervals, the tool can detect and report the excep- 
tions automatically. 
\blatility of Demand 
Objective 

To measure the volatility of demand, 'ilie volatility of 
demand can be measured by the coefficient of variation of 
ihe demand. 'ITie coefficient of variation of a random vari- 
able is equal to the ratio of the standard deviation to the 
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mean. A large value of the coefficient of variation indicates 
that the standard deviation is larger than the mean; the 
demand is therefore very volatile. While a small value of the 
coefHcient of variation indicates a stable demand (low levels 
of volatility). 
Input 

POS Data 138 or Shipment data by product (product 
group) or customer (customer group) 
Output 

Volatility measure 
Algorithmic Steps 

Compute mean of demand: 
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Objective 

To characterize demand by trend and level parameters. To 
assess changes in the dynamics of demand based on changes 
in trend. 
Input 

PCS Data 138 or Shipment data by product (product 
group) or customer (customer group) 
Output 

Estimation of trend and level. 
Algorithmic Steps 

For variable X, over time period 1=0 to n. 
Compute trend (b) and level (a) parameters: 




Compute standard deviation of demand: 

Compute coefficient of variation: 

5 

Lumpiness of demand 
Objective 

To measure the level of lumpiness of demand. The lumpi- 
ness is a measure of the time dispersion of demand. A 
demand pattern is said to be lumpy when the demand is 
concentrated in only a few number of time periods with 
numerous periods with no demand. 
Input 

POS Data 138 or Shipment data by product (product 
group) or customer (customer group) 
Output 

Cj the lumpiness measure. 
Algorithmic Steps 

C,=the percentage of the total number of time periods 

with demand equal zero. 
Demand pattern changes 
Objective 

To detect rapid changes in level and variability of sales. 
Input 

POS Data 138 or Shipment data by product (product 

group) or customer (customer group). 
Range for "normal" sales level and variability. 
Output 

Exception signal indicating a normal change in sales 
levels. 
Algorithmic Steps 

Compute normal sales levels and associated variance 
from the POS Data 138 for a given product by a 
customer. 

Alternatively user sets range for normal sales level and 
variability. 

Compute actual level of sales and variance each period. 
When the sales level fluctuates beyond the normal sales 

variance intervals, detect and report the exceptions. 
Demand history trend 



i=l-n*\ ^ 

, ^ /f 7 [2rt+ I) -(/!+ 1)^ 

a^ = lX-iKn+l)l2]nnHn+\)— " — ^ 
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Usage of MDA Models 


MODEL 


WHERE USED 


Volatility of demand 


[)ciiiand Characterization 




PSI 




VMR 


Lumpiness of demand 


t^cmancl CharactcrlEatioD 


PSI 




VMR 


Demand pattern ctiangcs 


[>eiiiaiid Characterization 




Bottom-up Forecast 




Top-down Forecast 




VMR 


E>cmand history trend 


[)emand Characterization 


Pareto analysis 


Demand Characterization 


PSI 



Sales Forecasting and Planning (SFP) 132 

40 The Sales Forecasting and Planning Module 132 contains 
all the models and routines that are used to generate fore- 
casts. These models and routines are used in the Demand 
Management Frame 130 for Bottom-up, Top-down 
forecasting, for the analysis of sales promotions and to 

45 estimate forecast accuracy. The SPP Module 132 is also used 
in the VMR Frame 250. 

The models and routines of SFP 132 fall into three 
categories: generic models common to the manufacturing 
and repair environments; models specific to the manufac- 

50 turing environment; and models specific to the repair envi- 
ronment. 

Scope and Objective 

Objective: Develop top-down and bottom-up sales fore- 
casts. 

55 Scope: Products and selected customers. 

Features: Statistical forecast based on historical sales; 
Statistical forecast based on point-of-satc data if warranted; 
Customer provided forecast and orientations; and Recon- 
ciliation tools to support expert judgment such as exception 

60 flags and sanity checks. 

Models Common to Manufacturing and Repair Environ- 
ments 

Three types of generic models are common to the manu- 
facturing and repair environments. 'Vhe first type consists of 
65 the various statistical forecasting models that can be used to 
forecast any time scries (demand or consolidated 
requirement). 'ITic second type concerns the estimation of 
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seasonality factors based on the same approach in both the 
repair and the manufacturing environmeDts. The third type 
of model relates to forecast accuracy estimatioo. 
Statistical Forecast Models 

The objective of the Statistical models is to generate a 
forecast based on the projection of some historical charac- 
teristics of the time series. These models can be applied to 
any time series in the coniext of demand characterization, 
bottora-up, lop-down forecasts and VMR. 

Below we discuss the following models: Moving average; 
Linear trend; Exponential smoothing; Holt-Winters model; 
Winter's method; Regression based forecasting model; and 
Autorcgressive/moving average model (Box Jenkins). 
Moving Average 

This conventional model is appropriate when the depen- 
dent variable is assumed to fluctuate around a constant 
(stationary) average value, i.e.: 

Jf^P+£p f-l. 2, . . . 

where p is an unknown constant corresponding to the mean 
of the series and €, is a random error with mean zero and 
variance cr^. Moreover, the model assumes that the variables 
{ej and hence {X^} are independent. 
Input 

Time series data to be forecasted (for example POS or 
shipment) 

Window n: number of periods to be considered for 
averaging. 
Output 

Future forecasts and their variances. 
Algorithmic Steps 

Compute next period forecast based on ihe average of the 
lasi n periods 



Estimate cr^ for o^: 



var (F,^j-X,^^)sO^(n+l)/n, estimated by cr^((n+l)/n) 
Linear Trend 

This conventional model Ls appropriate when the depen- 
dent (forecast able) variable is assumed to fluctuate around a 
trend line, specifled as a linear formulation of lime, i.e. 
X,=a+b.t+€, where e, is a random error with mean zero and 
variance a^. As above, {e,} and hence {X,} arc assumed to 
be independent. The model may be viewed as a special case 
of the regression based models below, with "time" as the 
only explanatory variable. 
Input 

Time series data to be forecasted (for example POS or 
shipment) window n. 
Output 

Future forecasts and their variances. 
Algorithmic Steps 
Select appropriate time period for trend estimation (the 

"window" of n periods). 
Compute trend and level parameters: 
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Estimate forecast based on trend projection 
(n + 1) 

b = n (i -/ + /7)X; - ft — - — 

F,,,-a+b{t^-l) 

Estimate variance of forecast 



20 Exponential Smoothing 

This conventional model is appropriate when the depen- 
dent variable is assumed to fluctuate around a constant 
(stationary) average value, i.e.: 

25 r-1, 2, . . . 

It puts progressively smaller weights on more remote obser- 
vations from the past: 



30 



f„,-«^,+«(l-a)A',_,+a(l-a)^A',.2+ . . . 



Input 



Time series data to be forecasted (for example POS or 

shipment) 
Smoothing parameter a 
Output 

Future forecasts and their variances. 
Algorithmic Steps 
Initiate Fj as Dq. 

40 

f„,-aZ),+(l-a)F^ 
[Estimate variance of forecast 



Estimate variance of forecast crror-Var 
(F,..-X,.,)-(c^)"/(2-a) 
Holt-Winters Model 

This convenlional model is also appropriate when the 
dependent (forecastable) variable is assumed to fluctuate 
around a linear trend line, i.e. when X, is specified by: 



with the associated assumptions regarding e. As with expo- 
nential smoothing, progressively smaller weights are attrib- 
60 uled to more remote observations. 
Inputs 

Time Series Data to be forecasted (for example POS or 

shipment). 
Smoothing parameters l>a^P>0. 
Outputs 

Future forecasts and their variances. 
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Algorithmic Sieps 

Initial and intercept and slope of trend line. 
Update recursively 

Set 

F, = aD, + o(l 4- -o)X,_| + a(l - - or - 4- 

a( t - a - Q-^X I - <r )^ Jf»-3 + o(l - - a/3)( 1 - a)^ 
Va4r,) = tt^{a^ + (l -o>^ - a - a)V(2 - a)} 

Estimate variance of forecast by 
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-continued 



to 



20 



1 



Estimate variance of forecast error by: 

C2-a)} 

Winters Method 

This conventional model is appropriate when the depen- 
dent (forecastable) variable is assumed to fluctuate around a 
linear trend line modulated by seasonality factors, i.e. 
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lb: Define Go=(V2-Vl)/N as the initial slope estimate. 

Ic: Set So=V2+Go (N-I)/2, as an estimate of the value 
of the series at time t=0. 

Id: Compute initial estimates of seasonal factors; these 
are obtained by dividing each of the initial observa- 
tions by the corresponding point on the line connect- 
ing Vj and V,, i.e., compute: 

le: Average seasonal factors as computed for the two 
seasons 



= ; f-o = ~ 



If: Normalize seasonal factors: 
Step 2: Update recursively: 

5,-aWC..^)+(]-a)CV,.,+C,.,) 

Step 3: Create forward forecast in period t for period t+x: 



fi is the initial deseasonalized level, G the trend or slope 
component and c, the multiplicative seasonality factor. 

Assume that the season consists of N periods, i.e. c,-c,,^ for 40 Regression Ba.sed Forecasting Models 
all t. The seasonality factors are normalized such that: this conventional model, it Ls ass-umed that the fore- 

castable variable X is determined by m(=l) cxogenously 

^ measurable (forecastable) variables Z'^\ ... Z"^ as 

Y^c, = N follows: 



Winters' method uses three smoothing factors, a,p and y as 

follows: 

Inputs 

Time Series Data to be forecasted (for example POS- or 

shipment). 
Season length N. 
Smoothing factors, ct, p and y. 
Outputs 

Future forecasts and their variances. 
Algorithm Steps 



where {E,J are independent with mean zero and variance cT. 
Inputs 

Time scries for {X,\ atxl all explanatory variables {Z^'^ 
Z^^), . . . , Z^"*} For example market share, total market 
value, installed base, GNP, etc. 

Time series data to be forecasted (for example POS or 
shipment). 
Outputs 

Estimates of coefficients a, b^, b,, . . . , b„ as well as cr'. 
Forecast for future value of X, on the basis of estimated 
future values of Z^'\ Z^~\ .... Z^'"\ 



Step 1: (Initialization). Use first two seasons (periods Algorithm Steps 

-2N+1, -2N+2, . . . , 0) to initialize values: 60 Use of standard multiple regression method. 

1 a: Calculate sample means for two separate seasons of Autoregressive/Moving average model (Box Jenkins) 

In this category of models, it is assumed that the fore- 
castable variable {X,} exhibits an autocorrelaled structure. 
1 The most general model of this type is specified as an 

^'^N.L 65 ARM A (p.q) model, i.e. 
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Where 

with {u,} independent with mean zero and variance a^. 
Inputs 

Time series data lo be forecasted (for example POS or 
shipraeni). 
Outputs 

Ideotification of optimal values of p and q. 
Estimates of coefficients Pj, . . . , and Yj, . . . , as well 
as o^. 

Forecast of future value. 
Algorithmic Steps 
Standard Box -Jenkins Algorithm and Process with fore- 
casted value computed as follows: 

Seasonality Factors Estimation 
Objective 

To estimate for each time bucket (quarter, month, week) 
its percentage of the yearly volume. 
Input 

Historic data by aggregated at the same level as the 

seasonality 
POS 

Shipment 

Total market volume, etc. 
Output 

Seasonality factors for each lime bucket. 
Algorithmic Steps 

Compute for each time bucket the proportion of the yearly 
volume it represents. 
Forecast Accuracy Models 

To estimate the accuracy of the various types of forecasts. 
Measures of forecast accuracy are used in various contexts. 

It is a proxy measure for the variance of the forecast when 
this one cannot directly be computed. Forecast variance is 
used in several inventory and safety stock calculations. 

Forecast error measures can also be used to identified 
those products and customers for which demand patterns are 
particularly unstable and thus require special attention. 
Forecast Error Calculation 
Objective 

To compute forecast error for the forecast produced n 
periods ahead. 
Input 

Actual Sales 

n periods ahead Sales Forecast (BU, TP, etc.). 
Output 

Average Absolute Error as of percentage 
Mean Square Error 

Table of forecast accuracy as function of n 
Algorithmic Steps 

Compute the percentage difference between the fore- 
casted and actual sales. 

Compute average absolute error and mean square forecast 
error. 

Exception Report Generation 
Objective 

To generate the list of the products or customers for which 
the forecast error was greater that a predetermined forecast 
error threshold. 
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Input 

Average Absolute Error 
Mean Square Error 
Forecast error threshold 
5 Algorithmic Steps 

Rank list in decreasing order of Average Absolute Error or 
Mean Square Error 
Output 

Exception list: ordered list of products for which the 

10 forecast error was higher than the threshold 
Models Specific to the Manufacturing Environment 

The particular aspects of the manufacturing environment 
call for specific models in the area of forecasting and 
planning. In particular a forecast approach that specifically 

J5 models the ordering pattern of retailers based on their 
replenishment policy and level of sale to the final consumer 
is considered. Approaches for the modeling of sales promo- 
tions are also proposed. 
Expert Based Model for Bottom-Up Forecast 

This discussion describes an algorithm to compute 
bottom-up forecasts designed so as to result in the best 
available point estimates of sales as well as a characteriza- 
tion of the degree of uncertainty surrounding these esti- 
mates. The system develops forecasts for each account, each 
model and each time-period. These are subsequently aggre- 

25 gated over all accounts. 

The analysis starts with a characterization of the account's 
anticipated sales pattern for a given model. Its order to the 
manufacturer are obtained as derivatives of this sales 
pattern, assuming that a specific systematic replenishment 

30 policy is followed by the account. The prevalence of a 
systematic replenishment policy (in the absence of capacity 
problems) is an important assumption but one which we 
have verified in our analysis of real retailer's behavorior. 
Previous investigations of point-of-sales data have estab- 

35 lished that the accounts' sales pattern is much more predict- 
able and regular than the normal order stream. It is therefore 
appropriate to start the forecasting process with a charac- 
terization of the account's sales pattern. Moreover, we 
envision that the inputs to the system be provided by the 
retailer in cooperation with or as a result of monthly raccl- 

^ ings with account representatives (buyers, logistics 
managers). The account representatives are clearly more 
familiar with their sales pattern than the resulting order 
stream to their supplier; their estimates for future orders are 
clearly driven by their anticipation of future sales. 

45 'fhe need to characterize the uncertainty of the manufac- 
turer's model sales stems primarily from the fact that this 
characterization is to be used as the foundation for inventory 
planning, i.e. the determination of the so-called I-line or 
lower bounds for the 1-Iine required to assure customer 

50 service levels which are compatible with the manufacturer's 
Quick Response targets. 

To assess minimum inventory requirements one needs to 
characterize cumulative sales over time rather than or in 
addition to sales per month. Extreme care needs to be 
exercised in aggregating sales over consecutive months 
since these are highly correlated. 'I'hus, a straightforward 
convolution of orders in consecutive months would lead to 
serious underestimates of the variability of cumulative 
orders and hence to the determination of inappropriately low 
safety stocks (minimum inventory Icvcb), exposing the 

^ manufacturer to undesirable frequent stockouts. These 
would result in inappropriate customer service, loss of 
market share and last but not least, a continuation of the 
vicious cycle preventing the manufacturer from establLshing 
rcUable forecasts in the first place. 

65 Our approach provides an exact characterization of the 
statistical distribution of cumulative sales based on a given 
characterization of the undcHying sales pattern. 
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The calculus used to characterize the distributions of 
account orders and aggregate orders is based on simple but 
rigorous probability calculus. 

The system is intuitive and fully transparent to all users. 
Below we give a brief outline of the inputs required by the 
system and the user interfaces which wc envision develop- 
ing to provide the user with various types of background 
information to facilitate the task of specifying forecast 
inputs. 

The calculus used to derive all order and aggregate order 
distributions is explained. 
Required Inputs; User Interfaces 

The user will be responsible for entering forecasts for 
specific account/model combinations under his/her respon- 
sibility. For any given account/model combination, forecasts 
are to be provided for the next 12 months on a rolling 
horizon basis. The user will be confronted with a main menu 
permitting a choice between: (I) whether to provide esti- 
mates of the accounts' sales (U) or orders (12); and (11) 
whether to provide estimates of monthly total sales (orders) 
(III) or to provide separate estimates (112) for 

(a) regular sales activities, and 

(b) Promotional activities 

We will strongly encourage LAMs to opt for 

(1) providing estimates for sales, and 

(2) providing separate estimates for regular and promo- 
tional sales 

If option (12) is chosen, the calculations described below 
will be circumvented and by default orders in consecutive 
months will be treated as independent. (This may result in 
important distortions as explained in the introduction but is 
unavoidable under this option; the user cannot be expected 
to estimate the intertemporal correlation pattern. It is con- 
ceivable that an "average" correlation factor may be inferred 
from historical orders.) 

All accounts managed by the three LAMs whom we have 
interviewed follow or would like to follow a simple replen- 
ishment policy of the following type: (a) the model's inven- 
tory position is reviewed periodically (e.g. once a week, 
once in two weeks, once a month); and (b) at review epochs 
the account places an order to increase the model's inven- 
tory position to a target level of a given number of weeks of 
future expected demands (e.g. 6 weeks, 8 weeks) unless the 
current inventory position is already above this target level 
in which case no order is placed. 

The formulae below are based on this type of replenish- 
ment policy which is characterized by two parameters only 
(the review period and the target order-up to level in weeks). 
This policy structure is easy to use and eBicient from more 
than one point-of-view. However, it will be easy to make 
appropriate modifications should it become apparent that 
other types of replenishment policies are used by some 
accounts. 
Inputs 

s,=sales in period t (random variable) 
V -E s, 

W=number of periods of future demands to which the 
inventory position is to be increased every time an 
order is placed. 
'ITie distribution of s, is obtained by fitting an appropriate 
distribution to the three point information provided by the 
user. We fit a shifted Binomial distribution: Let 
S,'"'"=minimum sa\cs for period t 
S,"""-maximum sales for period t 
S""'omost likely sales volume for period t 



Let s 
n-S," 
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and assume s, is Binomial (n,p) with 



10 



15 



e.g. p=(s™^',-Si'^-l)/n 

([x]- denotes the largest integer smaller than or equal to 

X) 

Outputs 

o^-order in period t 



o^=cumulative orders in periods 1, . . . , t 
IP,=inventory position at end of period t after placing an 

order ("inventory on hand+ou Islanding orders) 
T,-target order-up to level at end of week t 
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The following recursive relationships hold (assuming back- 
logging; the equations are easily adjusted for the cost of lost 
sales) 



(1) 
(2) 



(3) 



We assume here that the s, — variables are independent of 
each other. 

Calculating IP, and o, — Distributions 

The distribution of the IP, — variables can be computed 
recursively. Observe the IP,^^ and s, are independent of each 
other. 



Hence, 



Prob[fP, = T,] 



(.r,_| 



\\Proi\s,i.\-r,] 



(4) 



(5) 
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For l'>T„ 



Prabl/P.-/'|/P,. j-/)-Piob(i -/-/'] 

Hence, Prob[IP,-l]- 



^ Prt;fr(/P,.u<r, = WProtAS, = 1-1' 
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Pfob[o,-0[/P,.,-/).Prol^s,Sf-r,l 



(6) 



(0) 
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PmHo, = 0) = ^ Probis. s I - T,]Pfvb{lL,.i = 1) 



(8) 



Calculating Cumulative Order Distributions The distribu- 
tions of cumulative orders, i.e. the (0,) — distribution can be 
computed recursively as well but only by computing the 
joint distribution of 0,_i and IPf^^: 
Case 1 Ut k'>k: 



PiiO,^ and lP^Tj{0,_^-k, /P,.jW>- 
P>{srt'-ki4-T,] 



for all IVT, 
Case 2 k'= 



■k: 



Pr[0, = i and IP, = V \ 0,_, = A and /P,., =11 = 

jPfis,= l-l'] if T,sl':il 
\ 0, ottierwise 



C9a) 



(9b) 



(10) 



25 



Thus 



PiiOrSC and lP,-T,]-Pf[0,^i-k, IP,^i'l\ 



Pi{s, =Jt' - it + 1 - T,j + ^ Pr{G,-\ - k' and fP^, = 1] Pris 
1=1' 

Pr[0, = A' and IP, = 1'] 



MO,-."*" and !P,.^-l\ 

PA^H-n 



(11) 
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Past Promotions Effects Estimation 
Objective 

To assess the total impact on sales of past promotions. 

Promotions perturb the regular pattern of sales and vari- 
ous types of promotional activities influence the sales vol- 
umes according to rather different patterns. The c*ijective of 
the model is therefore to assess the pattern of the impact of 
the promotion over lime. 
Inputs 

Times series of sales. 

Time period of the promotion. 

Class of the promotion. 

Type of the promotion. 

Intensity of the promotion. 
Outputs 

Overall impact of the promotion 

Profile of the impact over time. 
Algorithmic Steps 

'Ilie model is based on the use of time series models. First, 
an analysis is applied to a "censored" time series of sales 
volumes, in which all promotion (and after promotion) 
periods have been eliminated. One of several basic time 
scries models is applied to identify trend factors, seasonality 
indices and/or auto correlation structures. 

These basic time series models include exponential 
smoothing (weighted) moving averages. Winters' mcxiel, 
liox-Jcnkins models. The following Modified Winters' Pro- 
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cedure uses the demand (POS or shipment) data to remove 
seasonality and trend effects. 
Select time series model for estimation of demand for 

non-promotion periods. 
Initial Estimation of Level (including trend) at each 

Historical Period. 
Calculate the moving average of seasons, with each 
season having period P. If P is an even number, take the 
average of two consecutive moving averages to let the 
estimate centered on the lime period. 
Estimate Seasonal Factors 

Divide the actual demand by the centered moving average 
to obtain the estimate seasonal factor. Dampen the random 
effects by taking averages for similar periods in different 
years. Then, normalize the estimate seasonal factors that 
totals to P. Using the normalized seasonal factors remove the 
seasonality effects from the demand data. 
Estimate Level and Trend Terms 

Using the regression equation algorithm specified in the 
MDA 134 module, find the regression parameters for level 
and trend coefficients to fit the regression line. Using the 
regression coefficients remove the trend effects from the 
demand data. 

After an appropriate time series model has been selected 
for all non-promotion periods, interpolate base-line 
sales volumes in the promotion periods which would 
have arisen in the absence of the special promotion 
activities. 

Calculate the ratios of the actual sales volumes during the 
promotion periods and the calculated "base line" 
values, for each promotion period separately. This 
defines the impact curve of the promotion. 
Aggregate the impact curves pertaining to different pro- 
motion periods of a given type into a single curve using 
standard curve fitting techniques. 
The resulting impact factors for each of the periods 
belonging to and following after a promotion interval can 
now be used in future forecasting efforts. 
Future Promotion Impact Estimation 
Objective 

To estimate the impact of a future promotion 
Inputs 

Time period of the promotion 
Class of the promotion 
Type of the promotion 
Intensity of the promotion 
Outputs 

Estimated overall impact of the promotion. 
Estimated profile of the impact over time. 
Algorithmic Steps 
Search promotion calendar for past promotions with simi- 
lar characteristics. 
Assess impact of the planned promotion based on com- 
puted effect of similar past promotions. 
Identify generic profile of promotion impact correspond- 
ing to the planned promotion. 
Compute estimated profile of the planned promotion by 
combining estimated total impact and generic profile. 
Analyze Promotion Effects 

This analysis includes the following three types of pro- 
motional activities: price promotions, where the item price 
is reduced by a given percentage for a limited period of lime 
(e.g. 1-2 weeks); promotions via feature advertisements; 
and promotions via .-^cial store displays. 
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The characterization of the impact of promotional activi- 
ties is to be used as the basis of the statistical forecasting 
procedures in the Forecasting module of our DSS 10. It will 
also be invoked as guiding information in the bottom-up 
forecasting procedure. 5 

The sales promotion activities perturb the regular sales 
pattern in the commercial setting. Correspondingly, special 
events such as scheduled exercise in the defense application 
will also significantly change the usage of parts. Therefore, 
the models developed for analyzing the effects of sales lo 
promotions will also be applicable in understanding the 
effects of the special events in the defense setting. In the 
following section we employ commercial terminology for 
ease of explanation, while the models are equally applicable 
to both the defense and commercial applications. is 

It is both intuitive and extensively substantiated by sev- 
eral statistical studies in the conventional marketing litera- 
ture (see e.g., Blattberg and Naslin (1993)) that the various 
types of promotional activities influence the sales volumes 
according to rather diCferent patterns. Price promotions 
typically result in a significant increase in the sales volume 
during the course of the promotion period. The increase in 
the sales volume is due to: 

a. consumers increasir^ their normal purchase quantities 
to take advantage of the temporary price discounts; 

b. consumers making a purchase during the promotion 
period who otherwise would have waited until a future 
point in time; 

c. consumers being enticed into a purchase who otherwise 
would have opted for a different braiKl or who other- 
wise would not be in the market for this item. 

Only factor (c) results in a significant long term increase of 
the sales volume. The first two factors (a) and (b), on the 
other hand, cause an increase of the sales volume during the 
promotion period, but the increased volume is partially or 
completely compensated for by a decline in sales after the 
promotion period. i_i „ 

FIG. 31 displays a typical pattern for the percentage 
increases over time, resulting from a price promotion. As 
mentioned, the percentage increase is positive during the 
promotion period; the magnitude of the impact first 
increases and then decreases. The promotion period may be 
followed by an interval of time with a negative impact; the 
magnitude of the decline first increases and then decreases. 
See Ijcwandowski (1985) for more details. 

The impact of promotions via feature advertisements or 
special in-store displays may exhibit a similar pattern (as in 
FIG. 18); alternatively the impact of these types of promo- 
lions may be confined to the promotion period itself. 
Regression Models 

Our menu of regression equations consists of variants of 
the following basic equation used in Blattberg and Wis- 
niewski (1988) and with minor changes in Wiitink et al. 
(1987). 
Ut; 

S^= Weekly retail sates for item i at time t, 
Ri,='I"he regular (shelf) price of item i at time i, 
P^-The observed price (actually paid by the consumer) 

for item i at time t, 
D,- -The deal discount for item i al time I ((R.-,-PJ/R„), 
CPjf°'Yhc price of a competitive item j at time t with j not 

equal to i. 

X„=A dummy variable which equals I if a display is run 
for item i at lime t. es 

Y„aA dummy variable which equals 1 if a feature ad is 
run for item i al time t. 



L^=A variable representing deal decay, equaling kj-1 
with j being the time since the beginning of the deal and 
0<k<l, 

The basic regression model is: 



(1) 



All of the data required for this model are available in our 
data sources. The only possible exceptions are the CPj, — 
numbers which reflect prices charged for items provided by 
competing vendors. We foresee that the latter may not be 
available in some commercial supply chain settings. If so, 
the item 2,^yCPy^ is eliminated from equation (1). On the 
other hand, a trend and seasonality factors (expressed e.g. 
via indicator variables) may be added to equation (1). For 
example, if the year is divided into four distinct seasons, add 
the variables Z,,="l if period t is pari of season 1 (1»1,K, 3) 
(along with a trend term) to the right hand side of (1): 

The log-linear formulation in equations (1) and (2) has been 
shown to provide significantly better predictions than the 
simple linear formulation. The specification in the conven- 
tional Blattberg and Wbnicwski model implicitly assumes 
that the impact of a promotion is restricted to the promotion 
period itself and thai the magnitude of the impact exponen- 
tially dechnes over time. To allow for a general pattern of 
impacts as in FIG, 30, we are considering the following 
variant. Let denote an upper bound on the number of periods 
over which a price promotion exercises a significant impact, 
and let 

Ui,-1 if period t arises 1 periods after the beginning of the 
last promotion period, 



(3) 
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The coefiicienls of the above regression equations will be 
determined by using the generic regression routine specified 
elsewhere herein. 
Time-Series Models 

An alternative approach to analyze retailer promotions is 
based on the use of time series models. First, an analysis is 
appUcd to a "censored" time scries of sales volumes, in 
which all promotion (and after promotion) periods have 
been eliminated. One of several basic time series models is 
applied to identify trend factors, seasonalily indices and/or 
auto condition structures. These basic time scries models 
include exponential smoothing (weighted) moving averages. 
Winters' model, Box- Jenkins models. 'ITie following Modi- 
fied Winters' Procedure uses the demand (POS or shipment) 
data to remove seasonality and trend effects. 

Step 1. Initial Estimation of Level (including trend) at 
each IILstorical Period. 

Calculate the moving average of seasons, with each 
season having period P. If P is an even number, take the 
average of two consecutive moving averages to let the 
estimate centered on the time period. 
Step 2. Estimate Seasonal Factors. 
Divide the actual demand by the centered moving average 
to obtain the esiimate seasonal factor. Dampen the 
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random effecis by taking averages for similar periods in 
different years. Then, normalize the estimate seasonal 
factors that totals to P. Using the normalized seasonal 
factors remove the seasonality effects from the demand 
data. 

Step 3. Estimate Level and Trend Terms. 
Using the regression equation algorithm specified else- 
where herein, find the regression parameters for level 
and trend coefficients to fit Ihe regression line. Using 
the regression coefficients remove the trend effects 
from the demand data. 
After an appropriate time series model has been selected 
for all non-promotion periods, one can interpolate the 
so-called base-line sales volumes in the promotion periods 
which would have arisen in the absence of the special 
promotion activities. By calculating the ratios of the actual 
sales volumes during the promotion periods and the calcu- 
lated "base line" values, one constructs an impact -curve as 
in FIG. 31 for each promotion period separately. The impact 
curves pertaining to different promotion periods of a given 
type can next be aggregated into a single curve using 
standard curve fitting techniques, see FIG. 32. The resulting 
impact factors for each of the periods belonging to and 
following after a promotion interval can now be used in 
future forecasting efforts, as guided by our Forecasting 
Module. This approach follows that of Abraham and Lodish 
(1992) who have successfully adopted the methodologies in 
their earlier PROMOTER system to analyze retailer promo- 
tions. The PROMOTER model has four primary steps: (I) 
adjustment of the data for trend, seasonality, (2) elimination 
of data points influenced by promotion, (3) extrapolation of 
data points not influenced by promotion into promotion 
period, and (4) computation of promotion effect as the 
difference between this baseline and actual sales. 

TABLE 10 



Usage of SPP Models 



MODEL 



WHERE USED 



Statistical forecasting 
models: 

• moving average 
trend 

• cmoothing 
models 
Holt Winters 
model 

Winters mcttwd 

Regression 

based 

forecasting 

Autoregressive/ 

Moving average 

models 

Expert based forecasting 

model: 

SeasonDlfty factors 
eslimation routiDe 



Forecast accuracy 
routines: 

Forecast error 
calculation 
• Exception 
report 
general ion 

Past piotnotions impact 

estimation model: 

Regression 



l^emand Ctiaracterization 
fkittonvup Forecast 
Top-down Forecast 
VMR 



Bouom-up Forecast 

Ocmnnd Characterization 
Bottom-up Forecast 
Top-down Forecast 
t^l 
VMR 

Bottom- up Forecast 
Top-down Forecast 
FSl 
VMR 



•Sales Promotion 
Analysis 

Bouom-up Forecast 
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TABLE lO-continued 



Usage of SPP Models 



WHERE USED 



model 


Top-down Forecast 


• '1 ime series 




model 




Future promotion impact 


Sales E^omotioQ 


estimation model 


Analysis 




Bottom-up Forecast 




Top-down Forecast 



Models Specific to Repair Environment 
Definitions 

Equipment consists of modules that are composed of 
reparable items, and repairable items are made of compo- 
nents. 

Requirement: failure of an equipment. 

Consolidation policy: the policy of replacing the defective 
reparable item of a failed module with a good reparable 
item of an already defective module and reinstalling 
into the equipment. 

Defective ratio: ratio of number of defective reparable 
item to the total number of reparable items in a module. 

Target level: maximum defective ratio acceptable before 
a module can be sent back from the equipment location 
to the repair depot. The target level is one of the two 
pararaeteis of the consolidation policy. 

Raw requirements (pre-consolidalion requirements): total 
requirements generated by all equipment at the equip- 
ment location 

Consolidated requirements (post-consolidation 
requirements): requirements for equipment after con- 
solidation policy is applied to raw equipment require- 
ments (number of modules sent to repair depot for 
repair from the equipment location) 
Raw Requirements Estimation (for Boltom-up 
estimation). 
Objective 

To estimate raw requirements for all equipment located at 
a particular equipment location based on the planned activity 
(usage) schedules of the equipment. 
Input 

Equipment located at the equipment location. 
Activity schedules for all the equipment at the equipment 
location such as: 

equipment upgrade/maintenance schedules (preventive 
and breakdown maintenance schedules) 

activities (i.e., operation time, number of setups, cumu- 
lative operation lime) planned activity schedules for 
all equipment at the equipment location 

Output 

[istimalions of the raw requirements for each equipment 

at the equipment location 
Algorithmic Steps 

Establish relationships between raw requirements and 

activities of the equipmeni based on analysis of graphs, 

etc. 

Analyze the effects of activities on requirements using 

regression or time-series models 
Estimate raw requirements for each equipment given the 

equipment's planned activity schedule by the models 

used above. 

Consolidated Rcquiremenls Estimation (for Boltorn-Up 
Estimation) 
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Objective 

To estimate consolidated requiremeats for all equipmenl 
located at an equipment location based on the estimated raw 
requirements. 
Input 

Estimated raw requirements for each equipmenl at the 
equipment location and the time of requirement 

Batching parameter for the batching policy of the equip- 
ment location 

Consolidation policy (target level and the search rule) 
Inventory positions at the equipment location for modules 

and reparable items 
Performance measures: stock level, service level 
(availability of equipment), repair cost associated with 
repair at equipment locations and the repair depot. 
Output 

Estimates of consolidated requirements for all equipment 
at an equipment location 

Values of performance measures 
Algorithmic Steps 

Search under consolidation policy 

Identify repairable items to be sent to repair depot under 
batching policy of the equipment location 
Consolidation Policy 

A consolidation policy consists of two elements: a search 
rule for selecting the defective repairable item to be 
consolidated, and a target level, that is the maximum defec- 
tive ratio acceptable before a module can be sent back from 
the equipment location to the repair depot. 

Given a newly failed module of type 1 with a defective 
reparable item of type j, the consolidation policy defines 
which reparable item should be chosen out of which module 
to perform the consolidation. The chosen repairable item 
should already be part of a module with at least one 
defective reparable item but containing a good component of 
type j. The search rule select the reparable item for consoli- 
dation among all such defective modules. The following 
search rules are considered: 

Carry out the search for defective modules of type I only. 
Sort the defective modules of type I in decreasing order of 
the defective ratio and starting from the lop of the list, select 
the first module that has a good component j in it, if one 
exists. If not, sort all the other defective modules in decreas- 
ing order of the defective ratio and starting from the top of 
the list, select the first module that has a good reparable item 
j in it, if one exists. If not, (consolidation cannot take place) 
replace the failed module I with a good one, if one is 
available at the equipment location. If not, equipment 
becomes unavailable until either a consolidation or a 
replacement can be made. 

Determine all module types for which stocks of good 
items at the equipment location are below a threshold value. 
Sort the defective modules of all such types in decreasing 
order of the defective ratio and starting from the lop of the 
list, select the first module that has a good reparable item j, 
if one exists. If not, sort all the other defective modules in 
decreasing order of the defective ratio and starting from the 
top of the list, select the first module that has a good 
reparable item j, if one exists. If not, (consolidation cannot 
take place) replace the failed module of type I with a good 
module of type I, if a good one is available at the equipment 
location. If not, the equipment becomes unavailable until 
either a consolidation or a replacement can be made. 

Son the defective modules of all types in decreasing order 
of the defective ratio and starting from the top of the list, 
select the first module thai has a good reparable item j in it. 



to 
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if one exists. If not, (consolidation cannot take place) replace 
the failed module of type I with a good one, if one is 
available at the equipment location. If not, equipment 
becomes unavailable until either a consolidation or a 
replacement can be made. 
Batching PoUcy 

The batching policy is defined by the size of a batch, THl, 
(THl can be equal to 1). The inventory policy is in the form 
of: count the number of defective modules with defective 
ratio greater than the target level. If this number is greater 
than Till, then send THl units of repairable items to the 
repair shop else wait until this condition is satisfied. 
Consolidated Requirements Estimation (for Top-Down 
Estimation) 
Objective 

To estimate consolidated requirements for all equipment 
located at a particular equipment location based on historical 
data. 
Input 

Time series of consolidated requirements for each equip- 
ment locations. 
Output 

Estimates of consolidated requirements for all equipment 
at an equipment location 
Algorithmic Steps 

Use a conventional Kahnan filter based algorithm and 
conventional statistical forecasting methods to estimate 
consolidated requirement for the equipment 
Determining a Repair Plan 
Objective 

To determine a repair plan based on aggregate repair plan, 
and repair constraints (resource capacities and key compo- 
nent availability). 
Input 

Aggregate repair plan 

Available resource capacities and degree of flexibility to 

change resource capacities 
Key component availability (projected inventory 
positions, supplier and lead time information, inventory 
replenishment policy) 
Output 

Repair plan for the repair shop that is feasible with respect 
to the repair constraints (capacity and key component 
availability). 

Finished Goods Inventory Management (FGIM) 164 
Scope and Objective 

Objective: Decide where to stock, how much and when to 
replenish in (hybrid) made-to-stock/made-to-order environ- 
ment. 

Scope: Single and dual echelon. 

Features: Single and dual echelon inventory models for 
how much and when to replenish stocking poinLs. Cost vs. 
service trade offis to detennine where to stock. 
Deployment 

Models specific to manufacturing environment 
Overview 
Objectives 

lliis module contains a collection of finished goods' 
invenlorj' models enabling the selection and evaluation of 
inventory policies. The module returns an I- and P-line 
extended to a given horizon (of T periods) beyond the 
current period. At this stage, all of the models represent 
sellings where any given item is distributed to the customers 
from a single location. 
Input 

f'orecasts of mean demands per item, per period (S' line); 
standard deviations of demands per period per item (o* 
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line); mean production lead times for each period per 
ilem (L' line); standard deviations of lead limes for each 
period, per item (x' line). 
Output 

Inventory (I) line 

Production (P*) line 

Inventory strategies 
Models are classified as follows: MI. Models with Non- 
Lumpy Demand; and MIL Models with Lumpy Demand. 
Lumpy demands refers to settings where demands are spo- 
radic or experience extreme variability. The demand process 
for a given item will be classified as lumpy if the percentage 
of zero demand periods or the coeflBcient of variation of the 
demands is above pre-specified critical levels. 

Within the category Ml we next differentiate between: 
MI.l Models managing inventories or on an item-by-itera 
basis; and MI. 2 Multi-item models with joint capacity 
constraints. 

The choice between these two categories depends on 
whether or not important interdepeodencies prevail between 
the items (in the form of joint capacity constraints or joint 
cost structures). Within each of the subcategories Ml.l and 
MI. 2, different models can be selected based on the extent to 
which policy parameters are to be pre-specified by the user 
or computed based on an appropriate tradeoff between cost 
and service measures. 

MI Inventory Models for Non-Lumpy Demand 
MI.l Models for Independent Items 

As mentioned above, in this category inveutories are 
managed on an item-by-item basis. Different models need to 
be invoked dependent upon the extent to which policy 
parameters are lo be specified by the user Altemalively, the 
models to be used can be determined endogenously based on 
an appropriate tradeoff analysis or optimization of various 
cost and service measures. 
Ml.l.l User-Specified Base-Stock Policies 
Objective 

In this model, the user specifies an order-up-to or base- 
stock level as a given number of weeks of inventory. Based 
on this inventory policy, the model projects out an I' and F 
line for a scenario in which the forecasted mean demands are 
realized. 

Additional Inputs 

^rhe desired base-stock level for each period 
n,=number of periods of future forecasted demands in 
which the inventory position is to be increased at the 
beginning of period t, if below 
Algorithm 

Step I: Compute b,=S,+S,^j+ . , . +S^. (If n, is specified 
as a fractional value, equals: 

Step 2: Project V and P line. \jtM 

I(,=inventory position (inventory level plus outstanding 
orders) before ordering at beginning of period b L 

P,=produclion volume ordered at beginning of period t. 

Set Pj=bj-I„; project recursively for (a 1, ... , T-1: 

l,^,=max (b, l,)+P,-S, 

P,,,=max (b,^i-I,,i; 0) 
Step 3: Evaluation of various service and cost measures. 

a) e.g., expected average inventory level, 

b) probability of slock-out, 

c) fill rate or percentage of demands satisfied from 
slock. 
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d) number of setups, 

e) average backlog sizes. 

MI. 1.2 MIN-MAX Policies Based on Optimization of 

Aggregate Cost Measures 

Objective 

In this model, a policy is computed which minimizes the 
expected value of the aggregate of all relevant cost 
components, i.e. 1) setup costs; 2) inventory carrying costs; 
and 3) backlog^ng costs. The model is appropriate in 
settings where stock-outs are fully backlogged and where 
the inventory carrying and backlogging costs are propor- 
tional with the inventory levels and backlog sizes. 
Additional Inputs 

Holding cost rates per item per period (h* line) 
Backlogging cost rate per items per period (p' line) 
Variable production cost rate per item per period (c' line) 
Algorithm 

Step 1: Load S' (Sales), a' (Standard deviation), L' (Lead 
limes), x' (Standard deviations of lead times), K' (setup 
costs), h' (Holding cost rates), p' (backlogging cost 
rales), c' (variable production cost rates); 
Step 2: Fit appropriate demand distribution to S', a' lines. 

Fit appropriate lead time distributions lo L' andx' lines. 
Step 3: Solve for time-phased optimal (s,0) policy. 
Such a policy has for each period t-1, . . . , T, two critical 
levels s, and such that whenever beginning inventory 
position I,<s, an order is placed for (s,+Q,-I,) units. Param- 
eters (s„ 0,) are computed from the following recursion. 
Let: 

VXI)=exp6ctcd minimum costs in periods t, 

t+1, . . . , T given that period l starts with an inventory 

position of I uniLs. 
GXy)=expecled (inventory carrying and backlogging) 

costs associated with period t. (This function uses the 

lead time and demand distributions computed in Step 

2 as well as the h' and p' lines.) 
D,=demand in period t. 
Solve: 
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Note: the user is provided with the option to specify 
ranges for the production quantities x,^i, . . . , Xj-. 
These ranges may reflect capacity limits per item, or 
flexibility limits in view of prior determined P' and 1' 
lines. The ranges will be used to restrict the choice of 

X. 

Output 

For all t-1 ,T; 

x,*(I)=optimal order quantity at the beginning of period t, 

when inventory position=l. 
Step 4: Create I' and P' lines. 

Ij is known; set P,aproduction lot initiated in period I 
equal to X*, (I). Then project recursively for 

t-1; T 

I,.,-l,+x% (1,)^, 
(-1.1 

Step 5; Evaluation of various cost and service measures, 
as in Step 2 of model Ml.l. 
MM 3 Periodic Review Models Under Service Level Con- 
straints 
Object ive 

In this category of models the inventory policy minimizes 
expected setup and holding costs subject lo user specified 
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service level constraints. The user may choose between the 
two types of conventional service measures. 

Type 1 Service Constraints: 

Maximum permitted probability of a stock-out during ^ 
lead-time following poieniial order at beginning of a 
given period. Let: 

a ^maximum permitted likelihood of stock-out dur- 
ing lead-lime following potential order at begin- 
ning of period t. 
Type 2 Service Constraints: 

Minimum acceptable fill rate during lead time follow- 
ing a potential order at beginning of period. Fill rale 
is defined as the percentage of demand satisfied from 15 
stock. Let: 

p,=minimum acceptable fill rate during lead time 
following a potential order at beginning of period 
t. 

20 

The model is based on (he same assumptions as MI.l except 
that stock-out frequencies are controlled via service level 
constraints (of Type 1 or Type 2) as opposed to explicit 
stock-out or backlogging costs. 

Additional Inputs 25 
holding cost rates per item per period (h' line) 
maximum permitted stock-out probabilities per item per 
period (a' line), or minimum acceptable fill rates per 
item per period (P' line) 3Q 
Algorithm 

Step 1: Load S' (Sales), a' (standard deviations), L 
(lead-times), K' (setup costs), h' (holding cost rates), c' 
(variable production cost rales), a (service level type 1) 
or P' (service level type 2). (Lead-times are specified 
either as constants or via ranges with associated like- 
lihood for each value in the range.) 

Step 2: Fit appropriate demand distribution to S', a' lines. 
Determine lead time demand distributions. 40 

Let: 

LD,=lead time demand for order placed at beginning of 
period I. If lead time demand distribution is chosen 10 
be Normal (for example), Ihen set its mean and van- 45 
ance as follows: 

(=1 

/-I 



Step 3: Compute minimum inventory positions after 

ordering S,, via Reorder Point Algorithm, below: 
Step 4: Solve for time-phased optimal (s,Q) policy. 
Ut: 60 

V, (l)-expected minimum costs in periods t, t+l, . . . , T 
given that period t starts with an inventory position of 
I units. 

GXy)=cxpected inventory carrying and backlogging costs gj 

associated with period I. 
Disdcmand in period t. 



Solve: 



«/C if x>oi 
0 if x = 0 J 



/=1 T; all/ 



Output 

for all t=l, . . .,T; 

X*, (l)^ptimal order quantity ai the beginning of period 

t, when inventory position =1. 
Note: the user is provided with the option to specify 

ranges for the production quantities x^ x^^^, . . . , Xj-. 

These ranges may reflect capacity limits per item, or 

flexibility limits in view of prior determined P' and 1' 

lines. The ranges will be used to restrict the choice of 

X in (2). 
Step 4: Create 1' and P' lines. 

Ij is known; set Pj=prDduction lot initiated in period 1 
equal to x*i (I). Then project recursively for 
1=1, . . . , T 

l,,,=l,+x%(U-S, 

Step 5: Evaluation of various cost and service measures, 
as in Step 2 of model MLl. 
MI.2 Multi-Item Capacitated Periodic Review Models With 
Service Level Constraints 
Objective 

This category of models plans simultaneously for a com- 
plete family of items incorporating various joint capacity 
constraints. The model plans production quantities on the 
basis of estimated mean demands; however, minimum 
inventory levels are specified to satisfy user specified service 
constraints (of Type 1 or Type 2, see MLL3, above). The P 
and r fine are in this case determined by the solution of an 
LP-modcl. The user specifies whether minimum inventory 
levels are to be determined on the basis of Type 1 or Type 
2 constraints. In addition, the user chooses among a number 
of possible objective functions (performance measures) to 
select among feasible plans. 
LP Formulation 
Model 

LP formulation for 1 products (or product group) K 
resources (Key Component and/or Lines) sets and T periods 
Input 

S^=Demand for product i at period t 

s.,=Minimum amount of product i at the end of period I 

l,(,=lnitial inventory of product i at the beginning of the 

planning hori/jDn 
a„=Units of resource m, among resources in set 

required per unit produclion/repair of product i 
c„,=Units of resource m which becomes available at 

period I (In case resource m is a key component, c^q is 

ihe amount of it available at the beginning of the 

horizon under consideration.) 
Decision Variables 

P^,=Units of product i to produce in period t 
x„,v-Unils of product i to produce in period t using 

resource m in S^^ 
I,-,-lnventory of product i at the end of period t LP (A) 

Optimize: 

OVl, 0V2, 0V3 or 0V4 specified below: subject lo 

h,-\^Pirs„-ht foi 1-1, 2. / and /-I, 2, T (1) 

"^m ,« si^mir^i, fof k-I. 2, . . . , K, 2 I and t-1. 2, . . . 
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(2) 



2^j-o to ,2:,a„jX^,,<"2j_o „ ,c„ for each tcy component m and 
2...,T (2.1) 

2:/i„^^<-C„, for each line resource m and t-1, 2, . . . , T (2.2) 

t„£s„ for 2, . . . , [ and U.], 2 , T (3) 

x„i,gO for m in Sfo k-1, 2, .... K, i=l, 2, . . . , I and t-1, 2, . . . 
.T (4) 

Constraints 
calculate the inventory levels, 

(2.1) and (2.2) ensure that consumption does not exceed 

resource availability, 
ensure inventory is no less than prErspecified levels and 
ensure that production/repair is noD-negative. 
Output 

Feasibility of LP 

If yes, a production plan: P^, for i=l. 2 I and t=l, 2, 

. . . , T the corresponding inventory levels: for i-1, 
2, . . . , I and t-1, 2, . , . , T and remaining resources: 
slacks in (2.1) and (2.2). 

If no, display sources of infeasibility: surpluses in (2.1) 
and (2.2). 

OVl: Maximize maximum slack in resource con- 
straints (2.1) and (2.2) 

0V2: (Balance Workload), min 5:[a^-x„,yc„,] 

0V3: Minimize variable production and holding costs 
min 2:[c,^,,+h.,I,J 

0V4: Minimize maximum inventory in weeks min 
max,j;VS,.,] 
Algorithm 

Step I: Load S' (sales), o' (standard deviations), L' (lead 
times), h' (holding cost rates), c' (variable production 
cost rales), t' (standard deviations of lead limes); 
resource utilization matrix [a^] capacity levels [C„,]. 

Step 2; Determine lead lime distributions LD^ as in 

Step 2 of MI.L3. 

Step 3: Compute minimum inventory positions after 
ordering Sj, . . . , s,- via Reorder Point Algorithm. 

Step 4: Solve above LP. 

Step 5: Identical to Step 5 of model MILL 
Mil. Inventory Models for Lumpy Demand 

Apply to lumpy demand. The lumpiness of demand is 
measured as proposed herein. 
M3.1 Maximum Demand during Period 'n' Policy 
Objective 

This policy is suitable for low cost slow moving items 
with lumpy demand. 
Inputs 

S' line, cover period n. 
Outputs 

MAX level, inventory target. 

Frames using these models include 

PSI Planning Frame 160 (CF8) 

VMR Frame 250 (CF19 and CF20) 
Algorithm 

Step 1. Use method 1 to categorize lumpy demand 
Step 2. Determine *n'; a worst case scenario would be to 

set *n' as the replenishment lead-time. 
Step 3. Determine the maximum demand during period 

'n' and set it as the inventory target, MAX. 
Step 4. Compute I' line: 
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,_,+Tj,-£/.^^ for;=l, 2, . . . , y and /-I, 2, - - - r 



M 3.2 Expected Deficit MIN-MAX 
Objective 

This policy is suitable in cases where there are fairly 
expensive items that have lumpy demand. 
Inputs 

S' line 
Outputs 

Max level, inventory target 
Frame using the model includes 
PSI Planning Frame 160 
Algorithm 

Step 1. Use method 2 to categorize lumpy demand 

Step 2. Define expected deficit due to lumpiness as 
average amount that the quantity on hand is likely to 
fall before a replenishment order is placed. 

Step 3. Approximate the expected deficit (average period 
sales) as one-half of the beginning and ending quantity 
on hand between quantity-on-hand record updates. 

Step 4. Set ROP as safety stock plus demand during the 
lead-lime and expected deficit. 

Step 5. Set the MAX level as the ROP quantity plus the 
order quantity less the expected deficit. 

Step 6. When the inventory level reaches the reorder 
point, the difference between the targeted quantity 
MAX and the quantity-on-hand is ordered. Compute 
the r line: 

I.,_^+x^-d.,-l., fof y-l, 2 y and f-l, 2 T 

TABLE 11 
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Usage o[ FtjIM Models 



MODEL 



WHERE USED 



Inventory models for independent PSI Planning 

items with non-lumpy demand: VMR 

• User specified 
base-stock policies 

• Min-max policies 
based on 
oplimization of 
aggregate cost 
n%asures 

• Periodic review 
models under 
service level 
constraints 

Inventory models for multi-item PSI Planning 

with non-tumpy demand: 

• C^padtaied periodic 
review model with 
service level 
constraints 

Inventory models for lumpy demand PSI Planning 

Maximum demand during 
period '0' policy 

• Expected deficit min- 
max policy 



Models specific to repair environment Determining CSI 
^0 levels 
Objective 

To determine CSI level for each module type. 
Input 

55 repair shop repair time estimates 

consolidated requirements for equipment for the previous 
periods 
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Output 

CSl levels for each repairable item type 
Algorithm Step 

For each repairable item, sel CSI level to CSI^„, calculate 



68 



the corresponding performance measures. Based on 
values of the performance measures and the estimated 
consolidated requirements, change the CSI level and 
repeat. 

PerformatKe measures that can be considered for deter- 
mining the CSI level for each repairable item arc the total to 
cost of repair (setup cost+repair cost), and the fill rate 
(service level) al the repair shop. 

CSI level for each repairable item must be greater than or 
equal to the value of CSI^.„, which is simply the sum of the 
requirements during repair lime and a safety stock, is 
CSI„,„=E[ requirements overall equipment locations during 
repair time of one unit]+safely stock where safety slock is a 
user defined parameter, based on past requirements. 
Determining j'^regatc Repair Resource Requirements 
Objective 

This process includes the objectives: 

(i) . to estimate number of consolidated requirements for 
equipment triggering repair at the repair shop; 

(ii) . given (i). to estimate number of repairable items 
requiring nspair at the repair shop; and 

(iii) . given (ii), to estimate aggregate repair requirements 
at the repair shop 

Input 

CSI levels 

consolidation policy target level 
Types and numbers of repairable items in each equipment 
BOM for each repairable item (to go to the component 
level) 



Algorithmic Steps 

Check if aggregate repair requirements are feasible with 

respect to capacity constraints of the resources 
If not, change capacity levels of flexible resources, [f still 
infeasible, point out infeasibility and go back and move 
aggregate repair requirements forward or backward in 
time 

Determine key component requirements and time of 

requirement from aggregate repair requirements 
Check if aggregate repair requirements are feasible with 

respect to key component availability constraints 
If not, point out infeasibility in terms of component 
availability. Change key component availability (if it 
can be changed) equipment based on the purchasing 
policies for the components. If still infeasible, go back 
and move aggregate repair requirements forward or 
backward in time until a feasible repair plan is gener- 
ated. 

Aggregate Production Planning (APP) 162 

The Aggregation Production Module 162 focuses on its 
PS I Frame 160 application. The following two capacity 
checking models are identified and developed to support the 
25 Model Engine 20 requirements in the PSI Frame 160. 
Objective and Scope 

Objective: Facilitate the master production scheduling 
process. 

Scope: Finished goods production in some aggregate 
view. 

Features: Rough-cut capacity checking for finished 
goods; Major components (feeder plants) represented in 
constraints; and Ability to identify violated constraints. 
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Final estimations of consolidated requirements for the 35 Capacity Checking Models 



equipment 

Final estimated repairable item requirements correspond- 
ing to the consolidated requirements for equipment 

Repair data for each repairable item (operation sequence 
and repair time estimates for each operation) 
Output 

Aggregate repair requirements at the repair shop 
Algorithmic Steps 

Estimate number of consolidated requirements for equip- 
ment triggering repair at the repair shop 
Estimate number of repairable items requiring repair al 

the repair shop 
Estimate aggregate repair requirements at the repair shop 
Generation of a Feasible Aggregate Repair Plan 
Objective 

To generate an aggregate repair plan based on aggregate 
repair requirements, and repair constraints (resource capaci- 
ties and key component availability). 
Input 

Aggregate repair rcquiremcnts 

Available resource capacities and degree of flexibility to 

change resource capacities 
Key component availability (projected inventory 

positions, supplier and lead time information, inventory gQ 

replenishment policy) 
BOM for each repairable item family (to go to the 

component level) 
Output 

Aggregate repair plan for the repair shop that is feasible 65 
with respect to the repair constraints (capacity and key 
component availability) 



In the Capacity Checking models, the problem of check- 
ing whether there is enough resources to satisfy require- 
ments is formulated as Linear Programming Problems. 
These models are applicable to both the manufacturing and 
repairing environment in the PSI frame. The capacity check- 
ing models arc presented in manufacturing terms these 
models also apply to the repair environment and are used in 
the context of the Requirement-Supply Reconciliation frame 
to assess the feasibility of a repair plan. 
Sales and Safety Stock Sanity Check 
Objective 

Check whether there is a feasible production plan to 
satisfy given sales and safely stock requirements. 

Input 

I -The number of products to be considered. 
K.=The number of resources (production lines and key 

components) sets. 
S#- The set of resources. 
T=The planning horizon. 
S^-Demand for product I at period t. 
ISS.,=Safety stock of product I al the end of period t 
l,-o=Initial inventory of product I at the beginning of the 

plaruiing horizon. 
a„,=Units of resource m, among resources in set S^^, 

required per unit production of product I. 
c„,=Uniis of resource m which becomes available at 
period t, (In case resource m is a key component, c^ 
is the amount of il available at the tjcginning of the 
horixon under consideration.) 
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Output 

Feasibility of LP 
If yes, 

a production plan: 

P^, for i=l, 2, .... 1 and t=l, 2, . . . , Tlhe corresponding 
inventory levels: 

for i=l, 2, . . . , I and 1=1, 2, . . . /f and remaining 
resources (slacks in constraints (3) and (4)): 
I^_o „ ,c^-X^_o to ^flmi^mij key component m 

and 1=1, 2, .... T and c„,-2,a„-x^,, for each 

production line m and t=l. 2 T. 

If no, display sources of infeasibility (surpluses in con- 
straint (3) and (4)): 

2^:^ ia™X^«-2:,-o «. firn^ ^^^^ esch key component m 
and t=l, 2, .... T and 2,a„,x„,-,-c„, for each 
production line m and t=l, 2, . . . , T. 
Linear Programming Formulation 
Decision Variables 

Pi,=Units of product I to produce at period t, 
x„„=Units of product I to produce at period t using 

resource m in set Sj^, 
d„-Demand for product I during the period t, 
I„=Inventory of product I at the end of period I. 
Objective Functions 

Minimize maximum production line utilization (smooth 

production line utilization); 
Minimize 7. 

subject to 2^^.x^j/c^j<=z for each line resource m and 
t=l, 2, . . . , T. 
Minimize maximum inventory level: 
Minimize z subject to Iir<=z for i=l, 2, . . . , I and t=l, 

2, . . . , T. 
Minimize total inventory level: 
Minimize 2,2^,, 
Minimize total inventory cost: 

Minimize Z,X^ (.K^i^+PiX,') 

subject to l, =Ii,*-I„", l;/>=0 and l,r>=0 for 1=1, 

2 I and t=U 2 T 

where h„=cost per unit holding and 
p.,=cost per unit backlog of product I at the end of 
period I. 
Constraints 

Inventory balance formula 

Ii,-i+Pi/-d£x=I» for '=1. 2, . . . , I and t=l. 2 T. 

Resource allocation 

2™ in skK,u=P. for k=l. 2, . . . , K and 2, .... T. 
Key component availability 

^.r-o to f-ms f*^!" ^ach key component 
m and t=l, 2, . . . , T. 
Production line capacity 

2,a^,x„„<=c„, for each prtxluction line m and t=l, 
2, . . . , T. 
Safety stock requirement 

1^>=1SS,, for i=l, 2, . . . , I and t=l, 2 , T 

Non-negative resource allocation 

x„£,>aO for m in S^^, k=«l, 2, . . , , K, i=»I, 2, . . . , I and 

t=l, 2, T. 

Capacity Checking Model 

CCML User selected objective function subject to the 

above constraints. 
Frames using this model include rei planning (CFI3), 

VMR. (CF 20) 
TTiis LP formulation, with minor changes, is abo appli- 
cable to a repair environment, where reparable items corrc- 
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spond to products, repair requirements for reparable items 
correspond to demands for products, and broken reparable 
items awaiting repair at the repair shop correspond to key 
components. 

^ For the repair environment, key component availability 
constraint (the fourth constraint) should be modified as in 
the following to represent broken reparable item availability 
at the repair shop: 
10 4) Broken reparable item availability: 

to i^n.^mis<=^s~o to fiis fo"" e^ch repairable item i 
and t=l, 2, . . . , T. 
Objective functions and the other constraints in a repair 
environment will be similar to those of a production 
environment, which are given above. The LP model for the 
repair environment will either produce a capacity feasible 
aggregate repair plan that satisfies the repair requirements 
generated by reparable item failures or display sources of 
20 infeasibiUty. 

Production Requirement Feasibility Check 
Objective 

25 Check whether a given production plan is feasible with 
respect to aggregate production capacity and key component 
availability. 

Input 

30 I-The number of products to be considered. 

K-The number of resources (production lines and key 

components) sets. 
Sj.-The set of resources. 
35 T-The planning horizon. 

P^=Units of product i to produce at period I. 
a^,=Unils of resource m, among resources in set S^, 
required per unit production of product i. 
40 c„,= Units of resource m which becomes available at 
period t. (In case resource m is a key component, c^ 
is the amount of it available at the beginning of the 
horizon under consideration.) 

45 Output 

Feasibility of LP 

If yes, display remaining resources (slacks in constraints 
(3) and (4)): 

50 ^s-o lo iCmi-2:,_o ta ^i^mi^mis f^"" ^^^h kcy compOHcnt m 
and t-1, 2, . . . , T and c„,-2],a,„-x„,-, for each 
production hne m and t-1, 2, . . . , T. 
If no, display sources of infeasibiUty (surpluses in con- 
straint (3) and (4)): 

w Ji™«-^^-o for each key component m 
and t-1, 2, . . . , T and 3l,41„,-x„^-c„, for each 
production line m and t-1, 2, . . . , T. 
Linear Programming Formulation 

60 Decision Variables 

x„,-,«Units of product I to produce at period t using 
resource m in set S;^. 

Capacity Checking Model 

65 

CCM2: Objective function 1) subject to constraints 2), 3), 
4) and 6). 
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TABLE 12 
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Usage of AFP Models 



MODEL 



WHERE USED 



Capacity checking models: 

Sales and safety stock sanity check 
Production requiiemeot fciisibiUty 
check 



PSI Planning 
VMR 



Vendor Managed Replenishment (VMR) 252 
Overview 

This section describes the specifications of the various 
models used in Che VMR modules. The description is 
divided into three main categories: (1) Inventory Require- 
ments Setting Models, (2) Strategic Models, and (3) Opera- 
tional Models. The notation for these models is introduced 
as necessary throughout this section. 

The models developed in this section are based on prior 
results in the professional literature as well as from other 
sources. 

Scope and Objective 

Objective; Analyze contractual agreements with custom- 
ers; and Decide on what to ship, in what quantities and 
when. 

Scope: Selected products for selected customers. 

Features: Evaluate policy parameters such as bounds on 
customer inventories, target service level and delivery fre- 
quencies. Statistical forecast of retailers' sales (i.e. forecast 
of sales of PCEC's customers to their customers). Determine 
shipment requirements and delivery schedules. 

Inventory Positioning: The Multi-Item, TWo Echelon 
Model 
Overview 

This section presents two models; the first model 
describes an algorithm for the calculation of required ech- 
elon inventories. (Echelon inventory=inventory in transit 
from the plant to the DC+invcntory on hand at the 
DC+inventory in transit from the DC to the slores+inventory 
on hand at the stores.) The second model estimates the 
expected level of service provided at a certain D.C, given a 
delivery quantity. Two important parameters used in both 
models are the expected value and standard deviation of the 
lead-time demand. ITiese models compute the stock-out 
probability of today's delivery on the day of its arrival to the 
stores. This is based on the approximation that was devel- 
oped as part of prior research on the Multi-Item, Two- 
Echelon production/inventory systems. 
Setting Inventory Requirement: Model (R) 
Objective 

Tliis module computes the required echelon inventory 
levels (R' line) at the beginning of each review period over 
the whole planning horizon. Clearly, these requirements 
depend on the delivery frequency used (the requirements 
increase as the delivery becomes less frequent). Thus, the 
required invenlory levels (R' line) are calculaled separately 
for each one of the pre-specified delivery frequencies. 
Input 

Network structure. 

Demand forecast (means, standard deviations and disper- 
sion factor). 

Required service levels (in terms of stock-out 

probability). 
Set of possible delivery frequencies. 
Ijead-times from each plant to every DC it replenishes, 

and the average lead-times from every DC to the stores 

it supplies- 



Planning horizon specifications 
Output 

Required inventory lines (R' lines). 
5 Notation 

t(j — beginning period of the planning horizon (assuming 
that 'today' is the beginning of period number 1). 

T — the length of the planning horizon. 
JO R/(i,j) — required inventory level, of product j at DC I, at 
the beginning of period t, when delivery frequency f is 
applied. 

a^j — required service level for product j at DC I. 

— mean demand for product j at DC I during period t. 
(ff^ — standard deviation of the demand for product j at DC 

1 during period t. 
6^. — demand dispersion rate for product j at DC I. 
The dispersion rate is defined as follows: 
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(R.1) 



and is assumed to be constant over time. stores(l) denotes 
the set of stores replenished by DC I. Note that we do not 
require the data which represents standard deviation of 
demands at individual stores. The parameters 6',y's can be 
calculated (or even roughly estimated) by an observation of 
a set of historical stores' data. 

L^- — Lead -lime from the plant that produces product j to 
DC I. 

X^- — Average lead-lime from DC I. to its stores, for 
product j. 

Q — Set of 'quarters' into which the planning horizon is 
split. Each quarter is a continuous time interval con- 
sisting of one or more periods. 

Q^, IQ^I — Quarter number q and the number of periods in 
it (note that). 

F — The set of all possible delivery frequencies. Each 
delivery frequency f is specified as the minimal number 
of periods between two coDsccutivc delivery periods. 
The values f must be integral (for non-integral values, 
redefine the base period, e.g. half a week instead of a 
week). 

^'f/f") — l^^e mean and standard deviation of ihe demand 
for product j at all stores supplied by DC I, over periods 
t until t+L,y+-Hm (m^O is a parameter of these 
functions). 'Fhe term t+L,y++ra represents the expected 
time at which a delivery shipped from the plant at 
period t+m (next possible delivery time), arrives to the 
stores. 
Algorithm Steps 

For all product-DC couples (i,j) 

For all frequencies f in F 
time:=0 

For all 'quarters' q in 0 

for all periods t=l to 
timc:=time+l 

// compute the lime to next feasible delivery period, 

t_del. // 
l_del:»f-[(l+f-l)mod f) 
iime_to_DC:=t_dcl+Ly 
limc_to_stores;=lime_to_DC+iy 



10/21/2002, EAST Version: 1.03.0007 



6,151,582 



73 



compute the values 



(R.2) 



and 



(R.3> 



srd = • 0 



{R.5) 



Use (R.5) if Ihe demand in this part of the period is assumed 
to be independent of the demand during the rest of the 
period. Another way to calculate the siandard deviation can 
be, for instance. 

The inventory requirement for period time is now computed 
via 



(R.6) 



10 



for a part of a period use the following interpolation method: 
Let X be the period number and let 0<a<l be the fraction of 
that period. Then, (R.4) meao=a 



30 



End For (t) 
End For (q) 
End For (f) 
End For (i,j) 

Estimate Stock-out Probability for a Given Replenish- 
ment 

Quantity: Model (ORl): 
Objective 

For a given replenishment quantity of product j, delivered 
from plant p(j) to DC I, this model estimates the expected 
projected stock-out probability. The stock-out probability is 
defined as the probability of shortage in at least one of the 
stores replenished by the DC The word "projected" refers to 
lead-time periods later, when goods are expected to reach the 
stores. 
Notation 

In addition to the notation defined up to this point, we 
define: 

DEIJV — delivery size, 
dale — dale of delivery. 

arr — (expected) arrival date of goods to stores 

X.y**"' — the echelon inventory level of product j in DC 1, 

al (period) time date. 
Algorithm Steps 

Use formula (R.2). with l_del=l, to calculate the 

expected demand over the lead-time. 



(t). Similarly calculate the standard deviation of this 
demand, 
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(1), via formula (R.3) (again, by setting t_del=l). The 
projected stock-out probability can be approximated by: 



X;f" *-DEUV 



J 



COR.1) 



15 



In certain situations the user may be interested in knowing 
the projected service levels for periods further than arr. Such 
interest may arise when no deliveries are planned for sub- 
sequent (number of) period(s). To evaluate the projected 
stock -out probability at period arr+k, when no deliveries are 
to be made during the following k periods (i.e. 
date+1, . . . , date+k), use the formula: 



{0R.2) 



StratcgicModel: VMR Coniraci Setup® 

20 

Objective 

This module consists of a set of models tailored to support 
replenishment planning by integrating: (1) service level 
25 requirements; (2) limits on customers' inventory invest- 
ments; (3) transportation costs; and (4) delivery frequency. 
Input 

Below is the input which is common to all of the models 
described in this particular discussion: 
Network Structure, 
Demand Forecast, 

Lead-times from each Plant to each DC and (an average) 

from each DC to its Stores, 
Planning Horizon Specifications, 
Current Inventory Positions, 

Transportation Cost Structure and Trucks Volumes, 
Products' Volumes (for Transportation Cost 
Calculations), 

Computing The Optimal Delivery Frequencies: Model (CI) 
Objective 

This model computes delivery frequencies from each 
plant to the DC it replenishes such as to minimize total 
transportation costs. The delivery frequencies are set such 
that given requirements on service levels are satisfied and 
such that constraints on average inventories are not violated. 
Input 

Inventory Requirements (R' Line, see Model R). 
Set of Po5Bible Delivery Frequencies, 
Required Service Levels (in Terms of Stock-out 
Probabilities), 

Limits on Maximal Inventory Investments (in terms of 
Weeks of Demand). 
Output 

Delivery Frequencies. 
Estimated Level of Service, 
Estimated Transportation Costs, 
ELstimated Inventor)' Levels, 
Notation 

\Vc use the same notation as in Model R (except for the 
notation for delivery frequencies) plus the following: 
Indices 

i— DC index 

j — product (module) index 
p— plant index 
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f — delivery frequency index 

s — indexof line segment of transportation cost function xlj-^ ^ /irj^^; fe (2,/ e Jp i,p,q (Ci.3) 

(the cost structure is approximated by a piece-wise s^f 
linear function) 

t — time index ^ „ , ^ . . r ^ • . 

q-quarter index ( ) pi Sets ^^'^ ^'^^ frequency is chosen for each tnple (DC, product 

I^tofailDCs and quarter): 

J — set of all products 

P^t of all plants ^ Y^r/^f ^ \ i.p.q (C1.4) 

F — set of possible delivery frequencies ^^'^ 
J' — all products sold to DC i. 

Jp— all products produced in plant p. Average echelon inventory (across all products) should not 

Transportation cost parameters (for deliveries from plant exceed a given level. This level is given in terms of weeks 
p to DC i) IS of inventory. Note that we subtract one half since X is the 

vol,^ — total volume of a single truck beginning inventory level (while we are interested in aver- 

c,y,— cost of full truck load (FTL) age over the period, i.e., X-^t/2): 

fix.p — fixed cost of less than full truck load (LTL) 

X;p^ — (right) end point of the s-th line segment (i.e., i i [/V~* / / v V 

ip^sD of the LTL cost function, rate^^— io^ |?t 2_j Zj ^'V ^ 

transportation cost rate for volumes in segment s [v jsjuhq^ jei''^Qii 

(i.e., in between t,^^_i and \pj)y for LTL shipments, 
v- — volume of product j (for cost calculation purpose) 

—upper limit on the average number of weeks of Upper bound on the number of full truck loads (FIT): 
inventory in DC i in quarter q. 25 

Decision variables nfT;'^ s ~~ f "^ '^'vl ^' ' 

X',^ — echelon inventory of product j at DC I (including [j^Jp ] 

outstanding orders) in the beginning of period t. 
S\j — delivery quantity of product] to DC I in period t. 

F^^^j,— an indicator set to 1 if in quarter q a delivery 30 Lower bound on the number of FTLs: 
frequency f is followed for the replenishment of DC 

1 by plant p. Otherwise it is set to zero. , _1_ ( y s'\-i i d i 

NFr,;p~number of full-truck-load sent to DC 1 from yol./\^.f^^ ' '^J 

plant p during period t. 
LTT,',y, — volume of LTL (zero if none) shipment sent to 35 

DC I from plant p during period t. Deliveries not send by the FTLs are sent by LTL: 

Y'-p^ — total volume of LTL shipment that falls into line 

segment (cost rate category) number s. Note that. ltl' - V vS'-NFT-' voI i u i (CI8) 

Z'^^^—an indicator set to i if the LIT shipment size is ^^^'^ " .f^ ' ^ "^ '^ ' ^' ^ ' 

larger than "^ip^-i', i e., segment s is partially or 40 ' 

entirely covered. Note that Z',^^ is always less or 

equal to Z',^^_i. Setting the transportation cost constraints (See 4.8.1): 

Algorithm Steps 

The following Mixed-Integer Linear Programming prob- y.'^^ = /.rz./ /. 1 (Ci.9) 

lem is solved: s 

Problem (Cl): 

r I (i;^..-V..-i)2.>^.i'SK^..'^(Tf^,-T^.i)Z,>yi,A',* (Cl.tO) 



MIN 

o^e aQg paP 



Integrality constraints 

Initialize inventory positions: SS 



NFT^'elntegers (CI. 15) 

System dynamics: (expected) beginning DC echelon 

inventory-{expccted) beginning inventory of last period+ 60 1" estimate the operating parameters, described above as 
delivery quantity to the DC during the last period -ex peeled part of the output of this model, use Model (C4) (described 
demand in the last period: later). 

Computing Maximal Average Levels of Service: Model (C2) 
;r,.'^,.'-'+5,/-'-/*^.'-' »./. f>i {C1.2) Objective; Given the delivery frequencies and limits on the 

65 avemge number of weeks of (echelon) inventories, this 
Beginning (expected) inventory level needs to satisfy the model calculates the maximal average service level that can 
requirement constraini, for the relevant frequency level; be obtained. 
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Input In the following problems we use Z^^ and Y'j^ with respect 

Inventory Requirements (R' Line, see Model R) ^ 
Delivery Frequencies T-^(x,,'~ii,jyai/, 

Limits on Maximal Inventory Investments (in terms of 5 below. 
Weeks of Demand). 

Output Problcrm {C2)?: MAX J] J] Wij-afj 

Estimated Level of Service "^^icj' 
Estimated Transportation Costs 
Estimated Inventory Levels 

l^^j^j.Qj^ (C2M) (Cl.l) only for the relevant value of i and teO^ 

„, . , • vj J 1 r>i 1 .u (C2'.2) (CL2) only for the relevant value of i and teQ- 

We use the same notation as in Model CI plus the ' ' ^ 

f ,1 • 15 (C2'.3) (CL5) (single constraint) 

^' See the discussion herein for details on (C2'.4)-(C2'.8): 

a'y — ^"projected" (i.e. "lead-time" periods after period l) 

level of service for product j in DC 1 at period t. ™ id' A) 

— a given set of periods in Vifhich replenishment (from "'"'if ^ ' 

plant p to DC 1) is permitted. 20 
w,y — values of objective coefiGcients (see discussion later) 
Algorithm Steps: 'Die following problem is of interest: (e.-o..Oz^^,,'sv.^'s(e,-e,_,>z^; ),t,s (C2'.5) 

Z,JiZj^^,'j,is~l, (C2- 6) 

Problem(C2):MAx2 ^W.^-tt?; 25 

^eQi^l r^Qq ^ji ^iM^^A } (C2*.7) 

" , , , (C2'«J 

(C2.1) (Cl.l) 

(C2.2) (C1.2) , relevant value of I 

(C2-3)(C1.5) R^arks 
Formula used to approximate the "projected" level of ser- The weights w,y should be set such that 

vice (see Model (ORl): ^5 

Z 

To determine the appropriate weights one should consider 
No delivery can be made in periods that are not compliant ^^e relevant factors that need to be taken into account (e.g. 
with the given delivery frequencies priorities, demand volumes, etc.) In case that some products 

have low service levels, the problem can be resolved with 
^ , „ , „ . ^ . . . ,™ „ the addition of the following constraint 

-0 for all t<T.p ij,t (€2.5) 

Note that Problem (C2) is separable both in 1 and in q. In 

addition, in order to deal with the non-linear constraint ^^^"^ % pre-specified lower bounds on the level of 
(C2.4) we approximate the Standard-Normal cumulative Y^'^' ^f"" ^^'""^ ^""^ 

distribution function (<^) by a piece-wLse linear function 50 ° 

(with m segments); for further details, see below. _^ ^^^^ 

As in Model (CI), we define for the piece-wise linear °'j^'^'2^ Z^'^'J '^uf-'' 

function the parameters and variables (for further details, see 
below): 

m — number of ''segments" in the piece-wise linear func- ^''^ r|= 1. 

jjj^jj Minimizing Average DC Echelon Inventory Levels: 

Model fC31 

0. — the s-th breakpoint of the piece-wise linear function ^, ■ ■ ^ r . • , 

, „ ^ - .L .L . • L rn Objective: Given the delivery trequencies and required 

(s=0, m); I.e. the s-th segment IS given by [G^_ J, ■ , , l- ., . .l • ■ . 

60 levels, this model computes the minimal average 

number of weeks of inventories at each one of the DCs in 

— the slope of the s-lh segment of the piece-wise linear every quarter, 

function (s-I, . . . , m). input 
Z'f^ — the binary variables associated with this transfer- Inventory Requirements (R' Line, see Model R) 

65 Delivery Frequencies 

Y'y^ — the continuous variable associated with this trans- Required Service Levels (in Terms of Slock-out 

formation. Probabilities) 
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Output 

Estimated Level of Service 
Estimated Transportation Costs 
Estimated Inventory Levels 
Notation 

We use the same notation as in Model C2 plus the 
following: 

p(j) — ihc plant in which product j is produced, 

q(t) — the quarter to whicb period t belongs, 

R'iuj) — this is the inventory requirement as defined for 
Model R, but without the subscript f. 
It now refers to the given delivery frequency from plant p(j) 
to DC I in quarter q(t). 

AVG',. — the average echelon inventory level in terms of 
weeks of demand (for DC I in quarter q). 
Algorithm Steps 

For each DC I in I: 

Step 1: For each product j, jeJ': 

Solve the following problem: 



10 



25 



ST. 



(C3.I) (Cl.l) (single constraint) 
(C3.2) (CL2) 

Beginning inventories must satisfy minimal requirements: 



30 



End For (j) 

Step 2: For each q in Q 
Calculate the value 



(C3.3) 



35 



1 1 



(C3.4> 



40 



End For (q) 
End For (I) 

Computation of Operating Parameters: Model (C4) 
Objective 

Given a delivery plan (i.e. the values S',y), this model 
computes the following operating values: (1) estimated 
inventory levels, (2) estimated levels of service, and (3) 
estimated transportation costs. 
Input 

Delivery Plan (S^). 
Output 

Estimated Level of Service 

Estimated Transportation Costs 

Estimated Inventory Levels 
Notation 

p' — Set of all plants that replenish DC I. 
Algorithm Steps 
For each DC I in I: 

Step 1: Evaluate the expected (echelon) inventory posi- 
tions at the beginning of each period via the equations 
(CLI),(C1.2) 

Step 2: For each quarter q in Q 

2.1 IHvaluate the value AVG',- via (C3.4) 

2.2 Evaluate the expected levels of service ( ) via 
(C2.4). 



50 



60 
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2.3 Evaluate total transportation costs over the quarter 
(can be done by an external procedure) for each 
plant. 
End For (q) 

Check Compatibility of a Given Set of Constraints: Model 
(C5) 

Objective 

This model checks whether a set of constrains (service 
levels, maximal echelon inventory levels and delivery 
frequencies) is compatible or not. 

Input 

Inventory Requirements (R' Line, see Model R) 
Set of Possible Delivery Frequencies 
Required Service Levels (in Terms of Stock-out 
Probabilities) 

Limits on Maximal Inventory Investments (in terms of 
Weeks of Demand) 
Output 

Feasibility (Yes or No) 
Algorithm Steps 

For each I in I: 

Step 1: For each plant peP: 

Select the most frequent among the feasible delivery 
frequencies from plant p to DC I (this represent the less 
restrictive constraint). 

For this delivery frequency, evaluate the inventory 
requirements R'(i,j) by using Model R. 

Calculate the values X',y as in Model C4. 

End For (p) 

Step 2: For each q in Q 

Evaluate the value AVG', via (C3.4) 

Check that 

is satisfied. If not, STOP! the set of constraints is incom- 
patible. 

End For (q) 

End For (I) 

Dclcrmine Production and Delivery Schedules: Model (C6) 
Objective 

This model suggests both production and deUvery sched- 
ules which minimizes total tran^ortation costs and (in- 
plant) inventory holding costs. The plan is determined under 
service level constraints and constraints on average inven- 
tories at the DC (echelon) levels. 
Input 

Inventory Requirements (R* Line, see Model R) 
Set of Possible Delivery Frequencies 
Required Service Levels (in Terms of Stock-out 
Probabilities) 

Limits on Maximal Inventory Investments (in terms of 
Weeks of Demand) 
Output 

Delivery Frequencies 

Estimated Level of Service 

Estimated Transportation Costs 

Estimated Inventory Ixvels 

Estimated In-Plant Inventory Costs 

Proposed Production Plan 
Notation 

We use the same notalion defined up to this point plus the 
following; 
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Parameters 

— holding cost, for unit of product j (io plant p(j)), per 
period. 

inv^f — inventory of product j in plant (p(i)) at the 

beginning of the planning horizoo. 
M — "big" number (see (C6.5)). 
Sets 

— set of all DCs that carry product j. 
Decision variables 

PROD'^ — production batch size of product j in period t. 
INV'^^ — inventory of product j in plant p(j) at the 
beginning of period t. 
Algorithm Steps 

The following Mixed-Integer Linear Programming prob- 
lem is solved: 

Problem (C6): 



IS 



1€Q feQg peP 



S.T. 

(C6.1) (Cl.l) 

(C6.2) (CI .2) 
Initialize levels of in-plant inventories: 



25 



INV/-mv/ j 
Inventory dynamics 



((6.3) 



beginning inventory=last period beginning invenlory+ 
, production quantity in the last period-goods delivered 
during the last period: 

IN VJ - INVj-^ + PROD)-^ + PRODf^ - ^5//' /. f (C6.4) 



Delivery can be made only if period l is consistent with the 
chosen delivery frequency: 



35 



40 



Si, A 



M i, j, t 



(C6.5) 



(C6.6) (CI. 4) 
Sec (CI. 3): 



SO 



(C6.8) (C1.5) 
(C6.9) (C1.6) 
(C6.I0)(C1.7) 
(C6.ll) (CI, 8) 
(C6.12) (Cl.9) 
(C6.13) (CI. 10) 
(C6.I4) (Cl.U) 
(C6.15) (CI. 12) 
(C6.16) (CI. 14) 
(C6.t7) (CI. 15) 



(C6.7) 



60 
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options for Production Capacity Constraints: 
PRODy'^pfod/ j,i 



(6.18) 



This set of constraints represents individual limit on pro- 
duction quantity for each product in any period. 



(C6.19) 



10 



This set of constraints is relevant when the diflfcrent 
products, manufactured in a certain plant p, share critical 
capacity resources. Although (C6.19) represent a single 
constraint for each plant (in a give period t), more con- 
straints can be easily added. Note that both in (C6.18) and 
in (C6.19) lower bounds can be introduced. 
Limits on Storage Capacity 

Similarly to (C6.18) and (C6.19), analogous sets of con- 
straints can be constructed in order to express, for each 
plant: (1) limits on individual storage volumes, and (2) upper 
limits on total volume (value) of storage, respectively. 
Operational Models (OP) 
Overview 

In this section we describe a family of models, analogous 
to Models (C1)-(C3). The models are built to assist pro- 
duction and delivery planning for the short-lcrm horizon. 
The major characteristics of these models are: 

Rolling horizon planning: production and delivery plans 
are made frequently (even before the end of previous 
planning horizons), thus taking into advantage updated 
information about demands and production capacities. 
High level of details: capacity constraints are more 
detailed so that the resulting plan will both be feasible 
and smoothly translated into production orders. 
Flexibility in setting non-delivery periods: the user is 
allowed to specify periods in which deUvery cannot be 
made. This replaces the requirement for following a 
certain delivery frequency. For instance, even if there is 
a certain guideline on delivery frequency, it can be 
relaxed at any (arbitrarily chosen) period. This reflects 
in added flexibility, which is especially important in 
cases of unexpected, high levels of demands (i.e. when 
deliveries must be made quickly). 
The number of constraints (per period) is larger in these 
models, however, the planning horizon is usually much 
shorter than thai of the strategic model. In addition, since we 
do not need to select certain delivery frequencies there is no 
need to incorporate the integer variables F^,^y. 'ITiis results in 
a significantly faster solution time. 
Joint Production-Delivery Plan: Model (OPl) 
Description 

Ttiis model minimizes the total transportation and (in- 
plant) inventory holding costs (see Model C6 for more 
details). 
Notation 

'I'he notation here is similar to that of Model C6 with the 
addition of the following: 
Parameters 

req^ — requirement Cor echelon inventory level of 
product j at DC I in period t, in order lo maintain a 
certain level of "projected" level of service (see 
Model ORl for further clarification). This minimal 
level depends on the delivery schedule, sec Model R 
for explanation on how to calculate these values 
(very similar to the calculation of the values R'^ i,j)). 
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X, — the same as x,' but now without the quarter index. 
cap'pCk) — the availability of resource k in plant p, in 
period t. 

\'j(k) — the amount of resource k required for a pro- 
duaion of unit of product j in period t. 

storage^k) — maximal total volume/value (etc.) of 
inventory remaining at the end of period t in planl p. 

p'j(k) — the volume/value (etc.) of unit of product j in 
period t 

setup'y — setup cost to initiate a production batch of 
product j in period t. 

Sets 

NoDel,-p — set of periods in which no delivery is 
allowed from plant p to DC I. 
Decision variables 
PROD'y — production batch size of product j in period t. 
INV'^. — inventory of product j in plant p(j) at the 

beginning of period t. 
SEVj — an integer variable indicating whether a setup is 
required in period t for product j. 
Algorithm Steps 

The following Mixed-Integer Linear Programming prob- 
lem is solved: 

(OPt): MIN^ ^ \ci, . NFT;^ 4- • Z;'^., 4- rme!^^ ■ V,; J + 



S.T 

(OPl.l) (Cl.l) 
(0P1.2) (C1.2) 
(0P1.3) (C6.3) 
(0PI.4) (C6.4) 
Deliveries can be set to zero at any period the user chooses: 



(OP 1.7) (CI .5) 
(OP 1.8) (CI .6) 
(0P1.9) (C1.7) 
(OPJ.10)(C1.8) 
(OP 1.11) (CI .9) 
(OP 1. 12) (CI. 10) 
(0P1.13) (CI. 11) 
(0P1.14) (CI. 12) 
(0P1.15) (Cl.l'l) 
(0P1.I6) (C1.15) 
Production capacity constraints (see also Model (C6)): 



^ X'-lky PROD] S cap'^[k) p. /, k 



(OP 1. 1 7) 



50 



S^'-O M,t« NoDcl, ^ (OPl .5) 

Echelon inventory levels must exceed certain levels: 

X,/Sreq^.'ij,l (OP1.6) 



50 
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Storage capacity constraints (see also Model (C6)): 

^'^KytNVj 5 storagc^(t) p, f, k (OPl.l 8) 



Introducing setup costs: 

The operational model can be extended so as to include 
setup costs (and/or setup times) as follows: 



setup j-yfr; 



The lam 



is added to the objective function of Model (OPl). Appro- 
priate set of constraints should be added as well; for 
instance; 



20 



SET/e{0,l} 
PROD/SAf-SET/ 



(0P2.1) 
(OP2.2) 



This constraint is pertinent if product j requires a new 
setup in each period it is produced. (M is a "large" number.) 



PROD/SA/ (SET/+SET/-1) 



(OP2.3) 



(with SET°, initialized according to the production/non- 
production of product] in the last period before the planning 
horizon). The intuitive behind this constraint is that if a 
product is produced in a given period, no setup is required 
at the subsequent period. 

Maximizing Short-Term Level of Service: Model (0P2) 
Description 

The purpose of this model is similar to that of its long- 
term counterpart. Model (C2). In the same spirit of that 
model (C2), we change Model (OPl) as follows: 
Algorithm Steps 

(OP2): MAX2^^H>;;.a/j 
167- /e/ ^ji 



40 



S.T 

(0P2.1) (OPl.l) 
COP2.2) (0P1.2) 
(OP2.3) (0PL3) 
COP2.4) (OP1.4) 
(OP2.5) (0P1.5) 
(OP2.6) (OP1.7) 
(OP2.7) (C2'.4) 
(OP2.8) (C2'.5) 
(OP2.9) (C2'.6) 
(OP2.10) (C2'.7) 
(0P2.ll) (C2'.8) 
(OP2.12) (OP 1. 5) 
(OP2.13) (OPl. 17) 
(OP2.14) (OPl. 18) 
Remarks 

Constraints (OP2.7)-<OP2.11) use the piece-wise linear 
approximation to the Standard- Norm a I cumulative distribu- 
tion function (CDF), see below. 

For explanation about the coelBcients w^^, see Model 
(C2)^,. 

Note that in this case, in contrary to Model C2, the 
problem is not separable in I. This us due to tl»c capacity and 
storage constraints (01*2.13) and (01^.14), respectively. 
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Minimizing Average DC Echelon Inventory Levels: Model 

(0P3) 

Description 

This model is analogous to the long-term model, (C3). We 
modify Model (OPl) as follows: 
Algorithm Steps 

Step I: solve the following problem: 

(0P3): MINXZZ^-V 



S.T. 

(OP3.1) (OPl l) 
(OP3.2) (0P1.2) 
(OP3.3) (OPl. 3) 
(OP3.4) (OP 1. 4) 
(OP3.5) (0PL5) 
(OP3.6) (OPl.6) 
(OP3.7) (0P1.17) 
(OP3.8) (OPl. 18) 
Step 2: For each DC I: 
Compute the values 



(OP3.9) 

1 1 

AVGi = r 

m \J'\ 



End For (I) 



TABLE 13 



Usaec oF VMR Models 



MODEL 



WHERE USED 



25 



Inventory positioning models 


Strategic 


far multi-item and two 


Planning/ 


echelons: 


Operational 




Planning 


Setting inventory requirements 




Estimating Btock-om 




probability for a given 




replenishment quantity 




Strategic models for VMR 


Strategic 


contract setup: 


Planning 


Compuiing maximal average 




service levels 




Minimizing overage DC eclielon 




invcniory leveis 




Computing optima] operating 




pftiameters 




Checking compatibility of a 




given set of constraints 




Determining production and 




delivery schedule 




Operational models 


Operational 


Determining Joint production- 


Planning 


delivery plan 




Maximizing short-term service 




levels 




Minimizing average DC echelon 




inventory levels 
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Scope 

All components in planning bill of materials. 
Features 

Heuristic to identify the procurement policy to use for 
each component. The policies considered are: Just in Time; 
Bulk purchase, managed via stock policy, such as (s, S); and 
MRP calculus implying periodic purchase orders. Finished 
Goods Distribution Network Design (FGND) 292 
Objective 

Determine the number, location and capacity of distribu- 
tion warehouses from a given set of potential locations. 
Scope 

Distribution network excluding VMR arrangements. 
Features 

Use market demand projections to reengineer the existing 
distribution network. 

Global optimization of system-wide costs including 
inbound /outbound transportation, fixed and variable 
warehousing, and inventory carrying costs. 
Model Engine Utilities 22 

In addition to the seven modules defined above, there is 
also a group of general purpose numerical routines that are 
not specific to any of the above seven modules. These 
routines are collected into a design element referred to as the 
Model Engine utilities 22, as shown in FIG. 35A. Examples 
of the Model Engine utilities 22 include generic linear 
programming solvers, and statistical analysis routines. 
An Approximation of the Standard Normal Distribution 
Function 

In this section, we suggest few continuous, piece-wise 
linear approximations for the cumulative Standard Normal 
distribution curve. We use the following notation through- 
out: 



35 



40 



M 



if Po = -oo< 2 < ^1 
if ^1 ^Z<&2 

M ; 

if 9„.i a 2< 5„ = -i-c 



(A.1) 



This function consists of m segments, s=l, . . . , m. Each 
segment s, ranges from break-point 0^_j to break-point 6,, 
The slope of segment s is denoted by d^. Hence, any segment 
s can be written as the linear function 3^+5^ (O^-O^-i)- 
model we limit the functions to be continuous (although 
unnecessary), thus having 



50 



0 ft>ri=l 
(fl, -Oi-i) forja 2 



(A.2) 



Note that in order to define the piece-wise linear function we 
only require the values 6^, s-1, . . - , m-1 and t)^, 
s=2, . . . , m-1 (since 3i=3„"0). 

TABLE 14 



Suggested funaions to approximate 
normal distribution 



60 



Type 



Rcnxirks 



Component Procurement Policy Development (CPPD) 230 
Objective 65 

Determine which procurement policy should be used for 
which component. 



Symmetric, 
7 segments 



, - -Z7, 
.--1.8. 
> - -0.9, 
4 - 0.9, 
, - 1.8, 
6-2.7 



, - 0.039923, 
»- 0.164589 
^ - 0.351044, 
5 -0.164589 
, - 0.039923 



Enables to 
reach 

reasonable 
level of 
accuracy 
owr all 
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TABLE 14K:ontinued 
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Suggested functions to approximate 
normal distribution 



— Is a Binary variable (I^efO, 1,2,...}) that indicates 
whether) that indicates whether T covers any positive 
part of segment s; that is. 



lype 






Rcm^irJcs 








argument s 








values. 


Symmetric, 


I - -2-7, 


2 - 0.057692, 


Ixss 


5 segmeats 




3 - 0.660714 


accurate 




Oj - 1-4. 


64 - 0.057692 


then tlie 7 




,-2.7 




segments, 
but requires 
less binary 
dedsioQ 
variables. 


Asymmetric, 


. - -2.5, 


2 = 0.096904. 


Rcactics good 


7 segments 


2- -1.1, 


3 - 0.331213, 


accuracy 




3-1.1, 


4-0.151834, 


levels for 




4 - 1.7. 


5 - 0.063973 


the highest 




5-2.15. 


a = 0.021037 


cumulative 




«-2-9 




value*. 



JO if r> r„., 

' \ I otherwise 



(B.5) 



To modify the current LP/MILP we do follow the steps 
10 below; 

Replace each F(T) by the term 

m-l m 

15 1=1 



(B.6) 



Introducing Piece-wise Linear Function Into a Mixed- 
Integer Linear Programming (MILP) 

Consider an LP/MILP which minimizes a (linear) func- 
tion of the decision variables X-(X], . . . , X.J^^, . . . , Xj^) and 
their piece-wise linear functions Fj(Xi), - - - , Fj^^X„.), 
M^N. That is, an objective function of the type 



Add the following constraints: 

(s=l, . . . , ra) are the split of T into the segments. 
20 Hence, 



25 



(B.l) 



with all d,>0. Similarly to the variables Xj, , . . , Xj^, .... 
Xjv, the functions FXX.) can appear in the (linear) constrainus 
without any limitation; i.e. the constraints are of the type 



To maintain (B.5), 
Other constraints; 

l,t{0,l}; s-l,K,m 



(B.7) 

CB.8) 

(B.9) 
CB.IO) 



35 



(B.2) 



Mean 

This algorithm computes the statistical sample mean of a 
given time series for a given period of time. 



40 



For simplicity, but without loss of generality, we assume 
M=l. Also, for clarity, we rename the variable X^oT. We 
thus describe a technique that transforms the function F(T) 
into a new decision variable, say H, such that the relation- 
ship H=F(T) is maintained for any solution obtained by 
solving the new MILP. 
Algorithm Steps 

Let the function F:9l*-*3l, be as follows; 



The input for the routine is the time series, and time periods 
''^ that the mean is computed over. The output is the unbiased 
sample mean quantity 



50 



Fir\ = 



0 

nr,)+-<ii +ri(7'-ri) 

M : 

F{r,.t)+6,.t +7,'{T-T,^t) 



T = ro a 0 
r J o 0 < r S ri 
r, < T S ri 

M \ 
r,_ I < r S 
M : 

r„_| <T < r„ m ei 



(B.3) 



Standard Deviation 

The algorithm computes the statistical sample standard 
deviation of a given time series for a given period of time. 



F consists of m segments; segment s is given by [t:„_p x^]. 
We now introduce the following 2m decision variables: 

— Is a continuous variable (Y^eS*) that represents the 
part of segment s "covered" by T , s=l, . . . , m; that Ls, 



(B.4) 



gQ The input for the routine is the time scries X, and lime 
periods n that the standard deviation is computed over. 'I"he 
output is the unbiased sample standard deviation quantity 

Moving Average 
65 The algorithm computes the moving averages for a given 
time series for a given period of lime with specified aver- 
aging periods. 
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CoefScieni of Variation 

This algorithm computes the coeflScient of variation for a 
given time scries using unbiased statistical mean and stan- 
dard deviation. 



The input for the routine is the time series X, time periods 
n that the moving average is computed over, and the moving 
average period length K. The output is the moving average 
quantity 

Seasonality Factors and Trend 
Seasonality Factors 

The algorithm computes the seasonality factors for a 
given time series for a 12-month year period. The input for 
the routine is the time series, and time periods that the 
moving average is conoputed over (at least two seasonal 
cycles). The output is the seasonality factors. 
Trend 

The algorithm computes the trend information Cor a given 
time scries for a given period of time, "^rhe input for the 
routine is the time series, and time periods that the trend is 
computed over. The output is the trend value of the time 
series. 

There are several different methods to calculate the sea- 
sonality factors and the Urend in a time series. The most 
popular ones include Winter's conventional linear and sea- 
sonal exponential smoothing, and (multiplicative) decom- 
position method developed by the U.S. Census Bureau, and 
its variant X- 11 method). 
Correlation Coefficient 

This algorithm computes the correlation coefiScient for a 
given pair of time series with properly defined time periods 
(there might be certain shifts in time periods in the two time 
series). 



10 



c, = 

X 



The input for the routine is the time series X and the given 
lime periods n. The output is the coefficient of variation for 
the lime series c^.. 
Goodness-of-Fit (Measure of Accuracy) 

This algorithm computes the goodness-of-fit (measure of 
accuracy) for a given pair of time series: one is the original 
15 time series and the other is the simulated one. The input for 
the routine is the pair of two time series, and corresponding 
time periods used to compute the goodness-of-fit for the two 
time series. The output is the goodness-of-fit (one measure 
of accuracy) for a given simulated method. The measure of 
20 accuracy can take one of the following forms (assume that 
X=X,)i" is the original lime scries. F"(F^)j" Is the forecast 
time series and e,-X,--F- are the error terms): 



The input for the routine is the pair of two time series X and 
Y, and corresponding lime periods n used to compute the 
correlation coefGcienl for the two time series. The output is 
the correlation coefEcient r(X,Y). 
Curve Interpolation 

This conventional algorithm determines a curve with 
desirable shape to link a set of given points on a 
2-dimensional space. The input for the routine is the set of 
given points, and the desired curve shape. The output is the 
curve thai satisfies the required conditions. 
Weighted Sum of Two Time Series 

The algorithm computes the weighted sum of two time 
series. 

The input for the routine is the two time scries X and Y, the 
weight factors a and p and the given time periods n. The 
output is the weighted sum time series 



Mean Error ME = - e, 



Mean Absolute DevioUon; MAD = - > k,l 



Mean Squared Error MSE = 



StandardDfeviation of Errors: 3DE 
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X,-F, 

PerceniAge Error: PE, = — — 100 
Mean Percentage lirron - V PE; 

Mean Absolute Pfcreentage Error MAPE=-y \PEi\. 



45 Regression Equation 

This conventional algorithm computes the coelBcients of 
a regression equation for a given set of time scries. We will 
choose a standard computational routine to calculate these 
coelEcients. The input to this routine is the set of time series. 

50 The output will be the calculated coefficients of the regres- 
sion equation. 

Supply Chain Frame Manager 24 
Overview 

A Frame 16 is designed to integrate User Interfaces, 
55 models, analysis routines and data in order to address a set 
of pslated decision issues. The Supply Chain Frame Manager 
24 constitutes the backbone of the DSS 10 through which the 
User Interfaces, the models in the modules and the data are 
connected. 'Ilie Supply Frame Chain Manager 24 facilitates 
60 the integration of the client side of the system, with which 
the user interacts, with the server side of the system where 
the modules and the DSS Database 12 reside. 

'ITie Supply Chain Frame Manager 24 is responsible for 
two types of integration: System Integration and Functional 
Integration. 'Ilie System Integrator 310 (see nC 34) Ls 
responsible to interpret the client's request, dispatch the 
request to the appropriate servers and to cixirdinate Ihe 
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to the Model Engine 20. The second way to pass data to the 
Model Engine 20 is for the Frame Manager 24 to only pass 
the key information directly to the Model Engine 20. Then 
the Model Engine 20 accesses the data directly from the DSS 
Database 12 using the key information. This will be used 
when the amount of data needed by the Model Engine 20 is 
quite substantial, e.g. a situation of solving a Linear Pro- 
gramming model. The key information passed from the 
Frame Manager 24 to the Model Engine 20 will include the 



computation load and data access. The Functional Integrator 
312 provides the functionality associated with overall supply 
chain instead of individual frame. ITiese functionaUiies 
include Supply Chain Configuration, Domain Management, 
user access or privilege administration and performance 
monitoring or simulation. 
System Integration 

The Frame Manager 24 is responsible for the client-server 

integration in the DSS 10. In this aspect, the Frame Manager , . p.. r^co n . u »-) .u 

^ . ,. , . u n Hi J 1 location of the DSS Database 12, among others. 

24 provides the linkage between the Frames 16, Model lo ^^^^ ,h. .Sv..ie.m 
Engine 20 and the DSS Database 12; responds to the 
decision requests from the client programs by accessing the 
models and data; and maintains the "component objects" 
(e.g., object linking and embedding OLE objects) that share 

functionality between different Frames 16. Based on the 15 integrator 310 is logically the same as the relationship 

decision requests, the Frame Manager 24 launches the between the Model Engine 20 and the System Integrator 

appropriate object with the appropriate data, manages the 310. 

requests from different clients for the same service and The System Integrator 310 in turn is composed of the 

executes the appropriate server programs. The server pro- Client Manager 320, the Request Interpreter 322 and the 

grams execute the request, and return the results to the 20 Server Manager 324. The Client Manager 320 manages and 



The Client 314 only interacts writh the System Integrator 
310 part of the Frame Manager 24. The Functional Integra- 
tor 312 part of the Frame Manager 24 provides the func- 
tionality through the System Integrator 3 10. The relationship 
between the Functional Integrator 312 and the System 



Frame Manager 24. The Frame Manager 24 will interpret 
and return the results to the Frames 16. 

The high level architecture of the System Integrator 310 
is shown in FIG. 35 and includes a Client Manager 320, a 
Request Interpreter 322 and a Server Manager 324. 

The architectural design of the Frame Manager 24 reflects 
maximum flexibility and robustness of the DSS 10. The 
client side includes all the User Interface 18 of each Deci- 
sion Support Frame, such as Demand Management, Supply 



monitors the client connection. For example, it may discon- 
nect a client if the client's machine is down or if the client 
is inactive for extended period of time. The Server Manager 
324 manages the server side connection. It is responsible to 
25 start up and shut down servers. It is also manages disparch- 
ing. The Request Interpreter 322 is the one that the client 
directly interact with. It will parse the client request and 
generate request to the servers. It will consult with the 
Server Manager 324 before making connection to one 
Management, etc. The Frame Manager 24 includes two 30 specific server, 
major pieces, the Functional Integrator 312 and the System The high level object representation of the system inte- 

Integrator 310. Two other components running on the server grator 310 portion of the Frame Manager 24 is shown in 
side are Decision Support System Database (DSS Database FIG. 36 and the high level architecture is depicted in FIG. 
12) and the Mathematical Model Engines 20. The client 37, The implementation documentation can be found in 
program 314 talks to the Frame Manager 24. The Frame 35 Appendix C. 
Manager 24 is the one respwosible to call individual com- Functional Integration 

ponenis running on the server to fulfill the client's request. The Functional Integrator 312 enables the advanced user 

For example, a user is working on a PSI frame to develop to define the supply chain configuration, manages user 
production plan for a specific scenario. After deciding sev- access and privileges, supports and enables the customiza- 
eral key parameters, the user wants to check on the produc- 40 tion of the DSS 10, manages domains to support user defined 
tion capacity. The user makes this request from the User data groupings, manages user defined Scenarios 78 and 
Interface 18 (click a button or select a menu item). The ensures data consistency across the DSS 10, and dynami- 
request is sent to the Frame Manager 24. The Frame cally monitors the impact of the user's decisions on the 
Manager 24 interprets the request and determines that it performance of the entire supply chain by using supply 
needs to move the Capacity Checking Model to get the 45 chain simulation, 
answer. (In a more general case, it may need to call more Supply Chain Configuration 

than one Model to accomplish the job.) Then the Frame The Supply Chain Frame Manager 24 allows the 

Manager 24 determines whether a model Server already advanced user to specify the configuration of the supply 
running and on which machine it is running. If there is one, chain. 'ITie advanced-user will be able to specify the struc- 
it sends the capacity checking request, along with the 50 tural (static) elements of the supply chain. These include: 
necessary data, to that server. If there is no Server running Customers or Equipment; Products or Repair Items; Com- 
at that time, the Frame Manager 24 will start up one on a ponents; Production Resources or Repair Resources; For 
selected machine and sends the request there. Sophisticated each of these structural elements, the advanced user will be 
dispatching policies can be implemented at the Frame Man- able to define the various attributes such as; Names and the 
ager 24 to balance the load or improve response times. After 55 values of features; Group definitions; and Nodes and loca- 



thc Model Engine 20 finishes the job, it returns the result to 
the Frame Manager 24. 'Ilie Frame Manager 24 then syn- 
thesizes the result and returns the result to the client. 

When the Frame Manager 24 calls the Model Engine 20, 
it has two options in terms of passing the data. First, it can 
obtain the data from the DSS Database 12 and pass it to the 
Model Engine 20. This will be done when the amount of data 
that need to be sent to the Model Engine 20 is not very large. 
'Yhc advantage of this approach is that the particular Model 



tions. 

In addition, the advanced user will be able to define the 
inter-relationships between these structural elements. 'ITiese 
interrelationships include: Distances, costs, and flow limits 
60 on the arcs between the various nodes of the network; 
Customer-Product-Resource (Equipment-Repair Item- 
Resource) relationship matrix; Bill of Material structure that 
relates components to products; and Production Matrix that 
relates production resources (repair resources) to products 



Engine 20 docs not require the capability to access DSS 65 (repair items). 'Ilie data flow diagram asstxiated with the 
Database 12. Hul the data has to travel from DSS Database Supply Chtiin Network Configurator 330 Ls shown in FIG. 
12 to Frame Manager 24 and then from Frame Manager 24 38. 
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User Access and Privileges 

The DSS 10 is a secure system where a userid and 
password are required for access and is managed by a User 
Access and Privileges Manager 331. An account consists of 
a userid, password and membership in various groups. A 5 
user derives rights from group membership that can be 
individually amended. The DSS System Administrator is 
responsible for assigning each user to a group and assigning 
rights to every new account. The lowest access possible 
allows read only access to one specific frame, with no ability lO 
to save Scenarios 78 or domains. Each table in the DSS 10 
database 12 has a designated owner. Only the owners are 
allowed to update the DSS Database 12. A scenario can be 
used to update the DSS Database 12 when the user who 
generated it is the owner of the data table that needs update. IS 
Customization 

The DSS 10 is customizable to the application and 
environment where the tool will be used. The customization 
involves: Terminology and nomenclature. Modules and 
models in the Model Engine 20, Displays and reports, and 20 
Graphical User Interface objects. 

The first two aspects of customization are administered by 
the analyst/systems administrator. For the last two points of 
customization, the user has the flexibility to customize 
displays, reports and GUI objects. The DSS 10 uses the 25 
proper terminology in the User Interface 18 for the infor- 
mation presented to be clear and intuitive. The DSS 10 
conforms to the user's environment and nomenclature. The 



carefully construaed Data Domains. The Data Domain 
Database comprises two tables: Domain Description and 
Domain Definition. From these two tables, the list of avail- 
able user domains and the member tuples of each domain 
can be created and displayed for the user. The domain 
management interface can consist of multiple tree-views. 
Each tree-view represents the logical grouping of customers, 
products or resources. From each of the tree-views, the user 
can select the product, customer, or resource combinations 
and add the selection to the domain. The User Interface 18 
should optionally reflect the data availability, and the intrin- 
sic relationship between the customers, products, and 
resources. For example, if the user chooses a specific 
customer first, he should be able to choose only the products 
that are sold to this customer (or any product, depending on 
his preference) to make a domain. Since a customer (or 
product or resource) can belong to multiple customer (or 
product or resource) groups, the user should be able to 
visualize the groups in which the customer (or product or 
resource) is a member. This can be visually implemented by 
reversing the tree-view, based on user selected customer (or 
product or resource). This tree-reversal will display the 
bottom-up version of the tree, rather than the usual top- 
down. Data Domains can abo be dynamically constructed 
based on the features of the product. For example, a PSI user 
can use the domain management tool to define thai a data 
domain to consists of Televisions with 19" screen and GR3A 
chassis. The tool will then generate a data domain that 
consists of all the televisions with these features. The data 



DSS 10 uses a table of terminology to implement the ^ . ■ l j , l- ^ r-Loc- 

nomenclature suitable to the user's application environment. 30 f^^^^J'^^'^'^J^^ t^l^ 3^111^^' ^^t^L^^ 
Images on buttons as well as text are dynamically adapted to 
the local environment at either the time of installation or 
execution. Screen appearance elements, such as colors and 
fonts, are modifiable through a User Preferences window. 
The user has the ability to change the layout of screen 35 
elements. 

Domain Management 

The Supply Chain Frame Manager 24 provides the user 
with the ability to define combinations of products, 
customers, and resources to be reused in the context of 
various analyses. These are called Data Domains and are 
managed by a Domain Manager 332. 

Data Domains provide a convenient mechanism for the 
user to define the products and customers with which (s)he 
is interested in working. For example, an account manager 45 
can define a data domain that consists of the customer 
accounts that (s)he is responsible for. A data domain is a set 
of customer, product, or resource combinations. Data 
Domains may be used from different Frames 16. llie data 
domain can be defined at various levels of aggregation 50 
(resolution) along each dimension: Product/product group, 
customer/customer group and resource/resource group. A 
data domain is independent of a data source (forecast, point 
of sales, shipments). The data sources are determined by the 
type of analysis that is performed and are therefore contin- 55 that needs update. The Supply Frame Chain Manager 24 
gent on the frame where the data domain is used. For maintains the data consistency across the entire DSS 10 by 
example, a domain can be used in the context of the sales restricting the update of the DSS Database 12. Scenarios 78 
promotion analysis functionality and could also be used for have note fields to allow the user to enter free form corn- 
forecasting: different data sources will be used in order to ments. Scenarios 78 should have a date stamp to indicate the 
perform each analysis but both refer to the same data 60 lime of last modification. Scenarios 78 are typically defined 
domain. Not attaching a particular time range or data series within a frame and are associated with a user. Scenarios 78 
to the Data Domains facifitates their portability from func- are specific to users but can be accessed in the context of 
tion to function and frame to frame. The user ts allowed to different Frames 16, providing that the user has the adequate 
build, edit and delete Data Domains that are owned by the access privileges. This enables the output of an analysis in 
user. In addition, the user is allowed read-access to the 65 one frame to be saved as a scenario and used as an input in 
definitions of the Data Domairts of other users. 'Diis facili- the context of another frame. Scenarios 78, while Ijelonging 
tales a set of users to perform similar analysis and share to specific users, can be shared between users. A scenario 



interested in working. For example, a plant manager can 
define a domain that consists of products and production 
resources. An air force commander can define a domain that 
consists of aircraft and line repairable units. The domain can 
be defined at various levels of aggregation along each 
dimension. Once a domain is defined and saved, it can be 
retrieved and used in the context of various decision analy- 
sis. FIG. 39 shows the process of using the Domain Manager 
332, and also shows the operations of the Domain Manager 
332. 

Scenario Management 

In the context of the different Frames 16 users generate 
changes to databases or instances of visual objects that can 
be saved as Scenarios 78 which are managed by a Scenario 
Manager 334. Scenarios can contain: edited data, results of 
analysis, graphs and charts, and performance metrics The 
Supply Frame Chain Manager 24 supports the following 
functions regarding Scenarios 78: 

Save: Scenarios are saved in the local database. 

Load: Saved Scenarios are loaded. 

Edit: Saved Scenarios are modified. 

Delete; Saved Scenarios are deleted. 

A Scenario 78 can be used to update the DSS Database 12 
when the user who generated it is the owner of the data table 
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may be deleted only by the user who created it or the system late a feedback control. This feedback will make it possible 

administrator. A user should have the facility to load the to dynamically monitor the impact of his decision on the 

scenario from different workstations. A user should also be performance of the entire supply chain, 

allowed to load portions of a scenario into a dififerent frame. "^iiie discussion below begins with background on deci- 

For example, a user is able to save the top-down and 5 sion integration and the system architecture. Then, the 

bottom-up forecasts from the Demand Management Frame underlying supply chain simulation modeling logic with 

130, and load the top-down forecasts in the PSI Frame. The regards to data flow and process flow are described. Finally, 

DSS 10 should warn the user in case of data incompatibility. originality of such an approach to use a supply chain 

A user is able to save the models and the parameters that simulator for the DSS integration is discussed, 

were used to modify loaded data. The user is then able to jq High Level Architecture 

apply these models and parameters to different data sets. ^Yho Simulator 350 resides at the Supply Chain Frame 

A frame 330 has several forms 332 associated with it as Manager 24 as a Functional Integrator 312 together with the 

depicted in FIG. 40. If the user attempts to close a form on Network Configurator 330 and Domain Manager 332 as 

which data 334 has been changed, the user will be prompted shown in FIG. 37; Supply Frame Chain Manager— High 

to Save the changes to a scenario. Abandon Changes, or jj i^^^i Architecture. The Simulator 350 can be initially 

Update the actual database. Updating the actual database configured with product flow, network structures and 

requires necessary access privileges. A Scenario 78 is domain information with the other modules of the Func- 

anchored to a frame, and can have multiple forms associated ^^^^^^ Integrator 312. Then, the Simulator 350 will read 

with it. A Scenario 78 can be loaded into the frame to which n^aj^r decisions from the individual Frames 16 that will have 

it is anchored, in which case, alt the data and other infor- 20 impact on the total supply chain performance. Monte Carlo 

mation will automatically be loaded into the appropnate simulation will be carried out driven by demand processes 

locations. Alternately, a Scenario 78 can be opened to access captured from the domain information and replenishment 

specific data that are contained in the Scenario 78. This pgj decisions from the DSS Frames 16. Total systems 

feature will enable the user to load the data created in a performance representing the supply chain dynamics will be 

different frame to a different frame. To facilitate this tracked according to the performance matrices specified in 

implementation, forms are specified to have a pre-specified qsS specification. These mainly cover cost and service 

number of da la -"pockets." Elements of a scenario include: tradeoffs including fill rates and response times. The per- 

Header information for each of the data pockets in each of formance will be monitored in aggregation according to 

the forms of each of the Frames 16. For example, DM-1- various levels such as; nodes, echelons, distribution chan- 

[1]-P0S 1245 -Point of Sales Information May 25, 96; 33 nels and the total system. In essence, the architecture facih- 

DM-l-[2]-TD1245-Top Down Information May 25, 96; ^ates the primary objectives of complementing decision 

and DM-l-[3l-BU1245-Bottom Up Information May 25, integration among models to provide a cross-functional 

9^- optimization. 

Model and parameter information. For example, ARMA yj^^^^ Interface 

with (1,1) applied to Top Down data. 35 [j^^. interface 18 of the performance Simulator 350 will 

Graph and parameter information have three major features; network configuration, decision 

User comments and parameter settings and the simulation and monitoring. 

Date stamp Network Configurator 

Performance Monitoring Using Simulation The system will invoke the Network Configurator 330 

Two levels of integration required in supply chain Deci- 40 module of the Functional Integrator 312 at the Supply Chain 

sion Support Systems have been embedded in our DSS Frame Manager 24. Detailed features and User Interfaces 

architecture; data integration and decision integration to have been described in the previous sections, 

provide a Network Simulator 350 (see FIG. 37). The former Decision and Parameter Settings 

has been obtained by having a common Decision Support Parameter, frame decision settings and empirical demand 

System (DSS) Database 12, from which input data to the 45 distributions will be displayed in the editable screens. Tliese 

decision models are retrieved and outputs updated. By screens will also be accessible during the simulation run so 

having such bi-directional data flows between models and that the user can interrupt the execution and modify the 

the Database 12 a complete data level integration is realized. parameters interactively. The following screens are 

In order words, all decisions are based on consistent and included: Demand distribution screens and Frame decision 

up-to-date information. This is the primary level of integra- 50 screens. 

tion for a supply chain DSS 10. Perfonmance Monitoring and Simulation 

'ITie secondary level of integration is the decision inte- The user is able to visualize the impact of the decisions 
gration. The purpose is to avoid sub-optimization among taken at the level of one frame on the overall performance 
functional processes. An ideal case would be to have a "meta metrics of the entire supply chain. The Supply Frame Chain 
analytical decision model" which could optimally solve the 55 Manager 24 supports this performance monitoring function- 
entire supply chain wide problem. With the state of the art alily. In all the Frames 16 users can easily access the 
in decision sciences and computing, this is not. Tlius, in our "performance monitoring screen." The performance moni- 
DSS architecture, various Frames 16 are hnkcd by the toring screen displays global performance metrics that are 
performance simulator For instance. Forecast Data 146 available to all users and that cannot be deleted or modified, 
from the Demand Managcmcnl Frame 130 is used in PSI 60 'ITie performance is tracked and displayed along the: channel 
planning and VMR 250 frames, VMR schedules are entered (such as VMR, Non-VMR, etc.); echelon (such as supplier, 
to the PSI planning and so on. With this approach, it is plant, DC and stores); individual nodes; and the total system, 
necessary to have a supply chain wide performance simu- The performance monitoring screen also contains u.ser for- 
lalor to monitor the effects due to the systems dynamics mulated performance metrics that are customizable and 
along the supply chain to provide a functional integration. 65 available only to the user who formulated them. 
'Die purpose of such an integration is to provide the user Hie Supply Frame Chain Manager 24 supports the fol- 
visibility beyond his functional boundary in order to facili- lowing functions for user formulated performance metrics: 
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Formulate: a new user-formulated performance metric, Edit: Simulation Logic: Process Flow Description 

an existing user-formulated performance metric, and Delete: A more detailed process flow of the simulation engine can 

a user-formulated performance metric. The function "edit" be described in terms of cither the demand processes or the 

and "delete" are restricted to the user who defined the control rules. Two basic control rules considered in our DSS 

performance measure. 5 production (reconciliation) policies and replenish- 

The value of the performance measures can be updated (inventory) policies, 

each time the user modifies the value of a field in the local Demand Processes 

database associated with the frame in which the user is The pertormanceof the total supply cham mamly depends 

working or by using an expUcit recalculate function or at "PO^./^e control pohaes and parameter settm^ along he 

^ .„ / . f , multilevel raatenal and mformation flows from the supplier 

user-specified time intervals. to customers. Both independent and dependent demand 

Users can choose a hcker-tape to always display the ^j^esses will be supported. They dictate the way require- 

currenl values of user selected key measures. ^^^^^ ^^^j^ ^ generated. In the independent demand 

The User Interface 18 is designed to suppon the conven- customer orders are generated for aU nodes from random 

tional "Visual Interactive Simulation (VIS)" approach. distributions developed from the Forecast Data 146 at each 

According to this approach, the simulation can be carried out 15 Qocie. In the dependent case, customer order generation from 

not only in the batch mode but also in the event-by-cvcnl or the random distribution is applied only to the customer 

per iod-by -period mode. The performance metrics could be facing echelon. The demand for the higher echelons are 

viewed and parameters adjusted interactively. To facilitate calculated from the lower ones with the lead time ofiEsets. 

this approach; Inventory, service level and cost profiles for The following systems will be driven by independent 

each aggregated measure (such as node, channel or echelon) 20 demand processes: Vendor Management Replenishment 

wUI be displayed as time series graphs. This will highlight (VMR); Continuous Replenishment (CR); Reorder Point 

the systems dynamics along the chain. System (r, Q); Jusl-in-tirae (JIT); and Min-Max (s, S). 

Summary performance matrices will be displayed in the The following systems will be driven by dependent 

summary report screen or saved to a file. demand processes: Distribution Requirement Planning Sys- 

Simulation Logic: Data Flow Description 25 ^ems (DRP); and Materials Requirement Plannmg System 

The supply chain simulation model primarily mimics the (MRP). ^ ^ ^ ^ o-. r 

material and information flow controlled by the frame ^ ^^e ca^ of One-for-one (S-L S) system for the 

decisions along the supply chain (see FIG. 41). The Simu- [^P^'^ systems, Poisson demand process wdl be applied. 

■>«r«- u -u i J. . ui r u 1 K- u Demand generation will be carried out by an inverse irans- 

ator 350 is built around data tables for each node which are ^^^^ ^ ^.^^^ distribution. For high volume items, 

hnked according to the mformation and product flow. These 50 ^^^^^j .pp^^^jn^ion of forecast error will be used. For the 

data tables arc stored as simulated data m the system. ^j^^^^g^ empirical distnbutions will be used. Time series 

In the initialization phase, these data tables will be popu- forecast and its error distribution (or parameters) will be 

lated with inventory information including inventory obtained as frame decisions from Demand Management, 

position, OD hand, on order and schedule receipt. Then, these Replenishment Processes 

tables are connected using pointers according to the network 35 ^Qth pull versus push controls are supported. In the pull 

structure, order and product flow directions. Then, demand control system, inventory is depleted by demand and when- 

and lead time information is loaded from Demand Manage- ever it reaches the replenishment point an order is placed to 

ment Frame 130 through system integrator and appropriate a supplier. In the VMR, the supplier places a reverse order 

distribution is buih. Using the distributions, customer orders to the store. For the demand channel, inventory decision 

are generated according to the demand processes at the 40 processes (models) for the following pull systems will be 

customer facing echelon and replenishments are triggered included; Vendor Management Replenishment (VMR); 

according to the control rules along the logistics pipe line for Continuous Replenishment (CR); One-for-one Replenish- 

each event due time i"^"' (S-l- S); Reorder Point System (r, 0); and One-for-one 

The major inputs required are the decisions that wiU effect system for repair will be logically treated the same as the 

the total performance of the supply chain. Tlie following are 45 Continuous Replenishment m the commercial settmgs- 

included; FGDND or Network Configurator-Network ^ 'he push (plannmg) systems a time-phased plan for 

design and Product flow; Demand Management-Forecast P^^.T^ f ^'^f' established and replenishment is 

J 1 n 1 u . triggered based on the requirement, schedule receipt and on 

and forecast errors; ^ndor Managed Replenishment- ^^^f^ j^^^^^ ^^^^ ^^^^^^ ^^^^^^ „ ^ ^^^^^ 

Replenishment policy, Target inventory, and I>elivcry fre- DLstribution Requiremeni Planning Systems (DRP) 

quencies; PSI Planning— PMine and iLsvanation, and I line so similarly, for the supply channel, the following pull 

and its variation; Supply Management; and Component systems will be STipported: Just-in-time (JIT); and Min-Max 

inventory policy and parameters. 5^ 

Depending on the configuration of the network, other ''Hie push planning systems for the supply channel are: 

supply chain system parameters such as FG inventory policy Materials Requirement Planning System (MRP) 

and parameters may also be needed for the oon-VMR 55 Transportation and infonnation flow logic will be embed- 

channel. ded in the replenishment processes. The capacity limitations. 

The outputs from the model are based on the performance cost and lead time for various modes of transportation and 

assessment plan of the DSS 10 for a commercial setting information flow (orders) will be checked to execute the 

including the followings: Supply responsiveness. On-time replenishments, 

delivery performance. Fill rate, FG inventory levels. Com- 60 Reconciliation Processes 

poncnt inventory levels. Order cycle time, and Financial ITie production planning logic refers to the way MPS is 

measures. created. Given a PSI plan 190 for the planning horizon with 

The Simulator 350 builds up the above performance possible variation, the system need to track the dynamic 

metrics from the event-level (lowest) measures. This outcomes along the supply chain. 'ITiis will be carried out by 

"bottom-up" approach in simulation makes it possible to 65 generating the dynamic demand along the demand channel 

support user formulated performance matrices that will be and consolidating (hem to obtain the simulated S* line. Tlie 

cuslomi/-ablc. simulated S' line (line refers to as the time scries sales 
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information) will be checked against P' (production) and I' 
(inventory) lines of the PSI plan 190 to compute service fill 
rates. Then production plan P* line will be ofEsct by simu- 
lated production lead times. 

Once the actual P' line is established, component usage 
can be computed using the Bill of Material (BOM) tables. 
This usage is translated as requirements (demand) to the 
supply channel. Then, component flows along the supply 
channel will be traced according to the respective compo- 
nent replenishment policies and demand processes at each 
node following a similar logic as described in the demand 
channel. 

User Interface 18 

One of the primary objectives of our DSS 10 is to provide 
a decision support environment that facilitates the decision- 
making processes using quantitative models and associated 
business data. The interaction between the users and the 
DSS 10 during the decision -making process can be charac- 
terized as follows: The communication of process ioforma- 
tioD and management input; Formulation of decision prob- 
lems; Generation of problem solutions or evaluation of 
decision alternatives; and Coordination of the above. To 
facilitate the communication and coordination between the 
users and the DSS 10, it is necessary to choose the appro- 
priate User Interface 18 design paradigm. 
User Interface Design Paradigm 

The User Interface 18 is based on the conventional human 
computer interaction paradigm referred to as "direct 
manipulation". In this paradigm there is no clear separation 
of input and output. For example, in exercising a certain 
model the user may either evaluate the impact of a decision 
option by specifying the decision variables or generate the 
optimal values of the decision variables. In the former 
setting the decision variables serve as input while, in the 
latter setting, the decision variables constitute the output. 

Another characteristic of the direct manipulation para- 
digm is the quick feedback feature where a user initiates an 
action such as posiug a particular query through direct 
manipulation of some interface object and the system 
responds with reasonable speed. 
User-DSS Interaction 

In each Decision Suppoa Frame discussed previously, the 
users will be aided in making several decisions. The prin- 
cipal process underlying these decisions will serve as the 
basis for the design of the User Interface 18. 

A typical uscr-DSS 10 interaction (see FIG. 42) begins 
with the users reviewing 402 the initial conditions and 
default values related to a decision problem retrieved from 
the DSS Database 12. Then the users communicate their 
preferences through proper selection of options, specifica- 
tion of parameters and values, and choice of analysis rou- 
tines. The DSS 10 examines the inputs provided by the users 
and assists the users in resolving any inconsistency in the 
inputs. Then, to look for the solution of the prcrfilem, the 
DSS 10 invokes the decision logic 76 of the frame. The 
Supply Chain Frame Manager 24 associated with the frame 
executes the appropriate quantitative models and routines in 
the Model Engine 20. 'Ihe users can review the output 
through the User Interface display, and repeat the above 
process if warranted. 

The general guidelines for the preferred User Interface 
design are described in the next subsection. 
Design Guidelines 

Tlie general design guidelines are as follows: 

User Friendliness 

Intuitiveness: Conformance to established standards. 
Integrated graphical display: Simple and visually clean 
graphical screen layout. 
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User customization: Ability to customize the interface 

into user's desired style. 
Minimal typing: Use of menus, pull down lists and 

buttons. 
5 User Guidance 

Rexible sequence control: Ability to access the DSS 10 

functionality without a pre-imposed sequence. 
Context-sensitive on-line help. 
Semantic feedback: Use of visual and audio cues for 
10 confirmation and progress. 

Use of colors for clarity, focus and aesthetics. 

User Interaction 

Data visualization: Visual aids to interpret data. 
Object orientation. 
Local/remote concurrent usage. 

Single/group usage. Ability for muhiple users to col- 
laborate in decision making. 

Multiple levels of user expertise: Support for novice as 
well as advanced users. 

20 

Implementation Principles 

Consistency: Similar "look and feel" for user-interface 

objects across the DSS 10. 
Modularity: Reusable and object-oriented user- 
25 interface code. 

Configiu'ability: Adaptability to the specific user envi- 
ronment. 
Design Elements 

The key design elements for the DSS User Interface 18 
include; Frame GUI; and Standard Object Library. 

Frame GUI: Since the DSS 10 will be an interactive 
environment, we adopt the most common environment used 
for interactive computing, known as the WIMP environment 
which stands for Windows, Icons, Menus, and Pointers. A 
35 frame-specific graphical User Interface (GUI) in this envi- 
ronment is necessary to support the interaction between the 
users and the DSS 10 in a decision process. The Frame GUI 
is customized using a standard set of User Interface objects. 
An example of this Frame GUI is given in FIG. 43. 
4Q Standard Object Library: The standard set of the User 
Interface objects used to build Frame GUIs is contained in 
a standard object library. The forms, positions and contents 
of the objects are set according to the specific needs of each 
Frame GUI. For example, these are the sample objects in the 
45 standard library employed in the PSI DSS shown in FIG. 43. 
Selection: to choose among various action options 
Grid: to input data and display results 
Chart: to display input data and results graphically 
Command Button: to execute an action 
List Box: to list user choices 
Example Implementation Architecture 

The basic objective of the DSS 10, is to provide custom- 
ized decision support for the decision makers to manage an 
55 integrated agile supply chain. It generates the following two 
specific systems requirements: DSS 10 should provide deci- 
sion support capabilities that work with the prevailing 
information systems which is mainly data transaction based 
systems. 'Diese decision support capabilities may include 
60 data analysis, decision process modeling, scenario manage- 
ment among many others; and DSS 10 must integrate data 
from various sources along the Supply Chain Information 
Systems 15. This requires the DSS 10 to interact with 
multiple information systems to gather raw data and distrib- 
65 ute processed data. 

'ITiesc two basic systems requirements motivate the archi- 
tecture and the choice of the platforms. 
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Three-Tier DSS Architecture 

In an enterprise-wide supply chain, the potential users of 
the DSS 10 are decision makers with different operational 
responsibilities and concerns. The views about the supply 
chain and functional requirements for decision support may 5 
therefore vary accordingly. The data to support these func- 
tional requirements reside often on a number of infonmation 
systems possibly with different hardware and software plat- 
forms. 

Consequently, the DSS 10 needs to interact with the users 10 
through a unified User Interface 18 to address diverse 
business concems while it should also be capable of inter- 
facing with different Supply Chain Information Systems 15 
to gather and distribute data. 

To that end, we have developed a layered systems archi- 15 
lecture design for the DSS 10 as shown in FIG. 44 in which 
all major system components interact with each other in a 
layered fashion. Aside from other benefits, the layered 
design makes the choice of platforms as well as implemen- 
tation of individual system components relatively 20 
independent, and permits standardized interfaces among 
various system components. The DSS architecture can also 
be viewed as a three-tier architecture consistent with the 
commonly understood three-tier client-server infomaation 
systems architecture consisting of the User Interface 18, the 25 
Business Logic 350 and the Data Management tiers 352 as 
illustrated in FIG. 44. 

Each of the three tiers in the DSS architecture has its 
distinctive functional roles and presents various levels of the 
system complexities. The platform for the three tiers is 30 
preferably chosen to best fit the user's unique functional and 
system needs. The choice is complicated by the availability 
of a number of competitive software and hardware platforms 
and the realization that there may not exist a single "opti- 
mal" suite of platforms. In the following, however, we 35 
describe a suite of platforms that can best serve the general 
DSS 10 needs and also be in line with the forecasted future 
development trends in information technology and 
enterprise-wide distributed computing technology. 
Selection of DSS Development Platforms 40 

To support the supply chain wide decision making, the 
DSS 10 needs to be integrated, flexible, responsive and 
comprehensive. One major obstacle, however, is that most 
of the data required by the DSS Database 12 are stored in 
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Access 376 which, in turn, interfaces with the Supply Chain 
Information Systems 15 through either Windows ODBC 
(Open Database Connectivity) tools 378 or Microsoft SQL 
Server 380 in a client^server fashion. The Supply Chain 
Information Systems 15 can include data servers in IBM 
SQL/DS, UNIX Oracle, among other formats. 

The Windows NT 382 is operating systems for the local 
area network server while the User Interface 18 can be in 
any Windows environment (3.1 and above) 384. 

In this environment, it is important to establish the client/ 
server data linkage between the DSS Database 12 (Access 
engine) and the supply chain information system data serv- 



As described earlier, the DSS Database 12 is internal to 
the DSS 10 implementation and contains only the data 
needed for the execution of the DSS 10. The data in the DSS 
Database 12 is synthesized from a variety of sources in the 
Supply Chain Information System 15. The DSS Daubase 12 
can be interfaced in a Client Mode 30 lo the supply chain 
information sources for data retrieval and update, as needed. 
This client-server interface, rather than a hard link, has the 
advantages discussed below. It ensures that the DSS 10 can 
be linked to the heterogeneous information sources in the 
supply chain. This is particularly significant in the absence 
of an enterprise-wide integrated information system for the 
supply chain. It reduces the burden on DSS Database 
management by obtaining updated data only when neces- 
sary. It fosters independence of the DSS 10 for easy main- 
tenance. It facilitates development of the DSS 10 for a 
generic supply chain architecture and minimizes application 
specific customization. 

The architecture described herein is built upon the general 
client-server concept. In the following, we describe the 
hardware system architecture (see FIG. 46) for generic 
systems, in which the host 398 represents the Supply Chain 
Information Systems 15, and the PCs 400 in the Local Area 
Network (LAN) 402 supports the DSS 10 applications. This 
architecture supports storing the invention described herein 
on various types of storage including RAM, ROM, hard and 
floppy disks, etc. 

in the architechire of FIG. 46, we assume that the hosts 
398 contain the majority of transaction level data and they 
will communicate with an LAN 402 where the DSS 10 
resides. Here, we do not make specific assumptions about 
the type of the hosts (IBM mainframe or UNIX 
workstation). On the LAN 402, there will be a scrver(s) PC 



various Supply Chain Information Systems 15 that are based 45 ^ ^^.J^ Specifically, the 

~" older information and computing technology. 



on an 

designed lo support vertically integrated organizations, built 
in isolation, and usually very complex. Such systems are 
generally referred to as the legacy systems. Therefore, to 
meet business and systems needs, the DSS 10 environment 
should: provide common and easily understood interfaces to 
all users, enhance the current business knowledge and skills, 
model and incorporate business logic, and promote access to 
legacy data and application systems in a secure manner. 

The development platform environment 370 illustrated in 
FIG. 45 has been chosen as the preferred environment to 
meet the above requirements. 

In this development environment 370, Microsoft Visual 
Basic 372 is used to build the unified User Interface 18 and 
the Business l^gic 350 that includes the Frames 16, Supply 
Chain Frame Manager 24, system level services and Model 
Engine 20. Portions of the Model Engine 20 that require 
more efRcient and precise numerical computations are pref- 
erably implemented using the Visual C++ programming 
language 374. 

The Visual Basic codes 372 directly interface with the 
DSS Database 12. 'Ilic DSS Database 12 uses Microsoft 
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functions of the DSS 10 can be partitioned as illustrated in 
FIG. 47. 

Below we describe the basic system requirements and 
functions for the system components in the above diagram. 
I^: 

Basic Requirements: 

Local area network supporting standard protocols such 

as TCP/IP. IPX/SPX, Named 
Pipes/NetBEUI etc. 
PCs can run Wmdows NT or 95 
Basic Functions: 

Provide the communication media between client PCs 
to server PCs 

Permit external PCs to dial into the network using 

regular telephone lines 
Allow connection lo the IBM hosts 
Chenl PCs: 
Basic Requiremenis: 

Have sufficient speed and memory 
Have network connection (on the I^AN or dial-up 
through telephone line) 
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Can run Windows 95 or NT 
Basic Functions: 

Sep/e as OLE clients 

Provide primary User Interface 

Implement what-if scenario manager 

Contain localized database 
Server PCs: 
Basic Requiremenls: 

Have maximum speed, storage space, memory and 
network connectivity 

Run Windows NT, SQL Server and SNA Server 
Basic Functions: 

Be the OLE server 

Host main DSS Database 12 with a library of SQL 
queries 

Serve as the SNA Server to exchange data between the 

DSS DB and host data tables 
Implement model object library 
Contain external optimization solver 
Hosts: 

Basic Requirements: 
Standard IBM database and applications or UNIX 

based database 
Support any combination of the options (Ethernet, 

Token-Ring, or FDDI) 
SDLC 

X,25.0LLC, etc. 
Basic Functions: 

Provide raw supply chain wide transaction data 
Contain EDI or other connections with customers and 
suppliers 

Support overall business information requirement of 
the company 
Example of Use 
User Access and Privileges 

When the DSS 10 is invoked, the DSS logon dialog box 
will be displayed to the user (sec FIG. 48). Failure to enter 
a valid User ID/Password combination results in the DSS 10 
immediately terminating. Correct entry of a valid user ID 
and password results in the DSS 10 being started and the 
opening screen being displayed to the user. The user ID is 
visible as it is typed by the user, but the password is blocked 
to prevent casual observation while it is being typed. The 
user ID is checked against an internally maintained table to 
ensure authenticity and user's privilege. 
Opening Screen 

Once the user has successfully logged on to the DSS 10, 
the opening screen is presented. Presenting the opening 
screen and deciding which frame the user is able to access 
is the responsibility of the Supply Frame Chain Manager 24. 
The main feature of the opening screen is a graphical outline 
of the supply chain overlaid with the relevant Frames 16 and 
showing the relevant portion of the supply chain. The user 
may move the mouse pointer over any of the Frame Boxes 
and click within the box to launch the frame (see FIG. 49). 

'Die user may also directly access the Frames 16 from the 
Toolbar buttons. The user must have the correct privileges to 
access the selected group, or an error message will be 
displayed alerting the user that he does not have the correct 
privileges. 
User Preferences 

A feature of the DSS 10 available from the main DSS 
screen is the User Preferences Folder. This folder allows the 
user to change certain features of the DSS 10 to preferred 
settings. As(x;cts of the screen appearance, layout and func- 
tionality will be modifiable by the user. These preferences 
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are saved and remembered between different DSS 10 user 

sessions (see FIG. 50). 

Domains 

Select Data Domain 

5 The primary interaction screen for the Domain function- 
ality is the Select Data Domain dialog box (see FIG. 51). The 
purpose of this dialog box is to display a list of all domains 
available to the user. It also allows the user access to dialog 
boxes for, editing, creating and deleting user domains. This 

10 set of functions constitutes the core functionality for the 
domain object. 

The major features and functionalities of the Select Data 
Domain dialog box are discussed below. An area showing, 
in a graphical way, the available domains. Ttiis list is built 

15 from two separate lists of domains. One set of domains is a 
default list of domains available to all users. The second set 
of domains is a user-specific set of domains. This set of 
domains can be created, edited and deleted by the user. The 
default set of domains is immutable. Each domain is repre- 

20 sented by a folder. Double clicking on a folder selects the 
folder and adds it to the Currently Selected Domain text box. 
Double clicking on a folder expands the folder and shows 
the customer-product tuples that are within the domain. An 
area showing the currently selected domain name. A button 

25 to allow Loading of the currently selected domain. A Cancel 
button to allow the user to exit the dialog box without 
selecting any domain and without initiating a load operation. 
'ITic Cancel is only valid for operations performed on the 
current dialog box. Editing operation performed during the 

30 session will persist. An Edit Domain button to allow users to 
modify existing domains, create new domains and delete 
unneeded domains. This functionality is only available for 
user-created domains and not for default domains. 
Edit Domain 

35 The Edit Data Domain fiinction allows the user to create 
new, user-defined domains and add them to the list of 
existing domains. In addition, the edit domain window 
allows the user to modify existing domains arxl delete 
unneeded domains. The user can create tuples from a 

40 tree-like listing of all available products and product group- 
ings and all available customer/customer groupings. The 
user may add as many tuples to the new domain as neces- 
sary. The user must give the domain a unique name and save 
it. It is then added to the list of available domains for the user 

45 (See FIG. 52). 

The major features and the usage of the features of the 
Edit Data Domain dialog box are discussed below. To create 
a new domain, the user must click the Add New Domain 
button on the tool bar. 'Vhis will create a new domain in the 

50 list of existing domain and open a name change box over the 
name of the domain so the user may give the new domain a 
unique name. To add a new tuple to a domain the user must 
have a selected domain in the domain list. Next the user must 
click on a product or product group in the product tree and/or 

55 a customer or customer group in the customer tree arxl click 
the Add to Domain button on the toolbar to add the selected 
tuple to the selected domain. Only one product/product 
group and one customer/customer group may be selected at 
a time. Selecting a group will result in aggregated data for 

60 the selected group being displayed. If data for the members 
of the group will be needed, the system will assist the user 
by displaying the data at appropriate resolution. However, 
some analysis may require that all of the data for the 
members be loaded. A shortcut key will be provided to allow 

65 the user to select all of the products or customers that make 
up a selected group. 'Die user may select as many tuples as 
necessary. To remove a tuple from the new domain, the user 
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must select the tuple from the list of tuples to be added to the 
new domain and click the Delete button on the toolbar. To 
delete an entire domain, highlight the domain to be deleted 
in the list of domains and click the Delete button on the 
toolbar. The user will be warned that this action will result 
in the elimination of a domain from the DSS 10. If the user 
clicks OK, the domain is deleted. If Cancel is clicked, the 
domain will not be deleted. When naming a new domain: the 
new domain may not have the same name as an existing user 



will appear in a list box below the selected feature name. The 
user may then highlight the features desired. Immediately 
after the feature type (i.e.. Brand) is selected, a new blank 
feature type selection box appears to the right of the selected 
feature type. This allows the user to select a second feature 
choice to use as a selection criteria (i.e.. Subtype). Once 
again, the possible values are then listed in a list box below 
the selected feature type and a third feature type selection 
combo box appears to the right of the last selection combo 



domain nor the same name as an existing default domain; lo box. This process will repeat until there are no more feature 



and the domain name should be something descriptive to the 
user so he will remember what the domain represents. The 
user saves the new data domain and exits the dialog box by 
selecting the OK button. If the user exits without saving the 



types related to the products. The user may select all of the 
choices for the feature by clicking the Select * button located 
directly below the Feature Type dialog box. In the following 
example, the resulting domain consists of products in the 



new domain, he/she will be asked whether the new domain 15 "PROJ" product category with brand being "Fl", "PP" or 



S" and subtype being "P" or *'S". The products that satisfy 
these selection criteria are shown in the "Products" list. 

As the user makes selections from among the Feature 
choices, the list of products matching the selection criteria is 



should be saved. The user can exit the dialog box without 
saving the new data domain by clicking the Cancel button. 
Default domains cannot be added by the user. DefauU Data 
Domains are created and added to the DSS Database 12 by 

a systems administrator with this access privilege. The user 20 updated in the Products list box. The user may select a set 

may choose between four diifereot modes for viewing the of these selected products to use as the domain, or may 

Customer and Product trees as discussed below. The "Prod- choose all of the products selected using the Select button, 

uct View" enables the user to first click on a product or When the user has the desired set of products, OK is clicked 

product group in the Product tree. When a product or product to copy the selection to the Edit Data Domain dialog box. 

group has been selected, the Customer tree is updated to 25 Scenarios 78 

display only the customers and customer groups that are Scenarios 78 are the vehicle for saving and reloading 

relevant. The "Customer View" enables the user to first click experimental work. From each frame a user has the ability 

on a customers or customer group in the Customer tree. lo save a scenario to retain the what-if analysis work 

When a customer or customer group has been selected, the performed. Once a scenario is saved, it may be accessed by 

Product tree is updated to display only the product and 30 other users as a means of sharing analysis and planning 



results among different users. A scenario may also be used 
10 save the logic behind a business decision, so the factors 
contributing to the decision may be analyzed at a later date 
and possibly reused. 

When the user chooses Save Scenario from the File menu 
group, the Save Scenario dialog box is presented (see FIG. 
54). At the top of the dialog box is an edit box showing the 
name of the selected scenario the current information should 
be saved to. If the user wishes to create a new scenario, the 



product groups that are relevant. The "Customer- Product 
View" enables the user to first click on either an element of 
the Customer tree or an element of the Product tree and see 
the existing related elements in the other tree. The "Neutral 

View" displays all customer and customer groups and all 35 
product and product groups with no linkage between them. 
This view allows users to select mples without regard for the 
existing relationship between the products and a customer. 
The user also has the ability to reverse the tree and show all 

the parental relationships involving a selected element of the 40 name of the scenario is typed into this edit box and the data 

tree. This is accomplished by way of the Reversed check box will be saved under this new scenario name. Scenario names 

located at the top of the Customer and Product trees. By must be unique. 

clicking the check box the tree is reversed, based on the The user has write access to a Scenario 78 to save the 

currently selected element of the tree. Either a group or an modified information to an existing scenario. Scenarios 78 

individual product or customer may be selected. The tree 45 for which the user does not have write-privilcges will appear 

may then be rotated to show the groups it belongs to. To grayed-out in the Save 5>cenario dialog box, and (he DSS 10 

restore the view to the normal view, uncheck the check box. will not allow the user to save to this scenario. The user may 

'Hie user may deselect any selection made in a Product or also add a description to the scenario and this description 

Customer tree by clicking the Deselect button located above will appear at the bottom of the Save Scenario screen. This 

the desired tree. This will remove the highlight bar from the 50 is a free text area where the user may type any words to 

currently selected tree element and leave all elements of the describe the scenario. Each time the scenario is saved, the 

tree in the unselected stale. This is useftil if the user wishes Date Updated field of the scenario is automatically changed 

to select an element from only one or two trees, but not all. to the current date and time. The scenario is saved when the 

Make Product Set user clicks the OK button. If the user clicks the Cancel 

The Make Product Set dialog box gives the user an 55 button, the scenario is not saved, 

alternate way to make a domain which only consists of If the user wishes to load an existing Scenario 78 , the 

products and product groups (sec FIG. 53). Using this dialog Open Scenario menu choice on the File menu is selected (see 

box, the user may select groups of product numbers based on FIG. 55). Scenarios 78 that were created by other users 

features of the products. This function can be accessed from appear with a RO tag, for read only. These Scenarios 78 may 

the Edit Data Domain dialog box by clicking the Make 60 be loaded but cannot be saved. The user may always save 

Product Set button on the toolbar. This will open the Make these Scenarios 78 to a new scenario, if desired. 

Pnxiuct Set dialog box. Demand Management Frame 

First, the user selects a product category from the product The User Interface for Demand Management (DM) Frame 
category list. Then, the user selects a feature (or features) 130 provides the user with a con-iislent environment for 
that will be used as selection criteria(i.e., the Brand) in a 65 carrying out these five aciiviiies: Demand Characterization; 
combo box in the right part of the dialog box. Once the liottom-up Forecasting; Top-down Forecasting; Sales Pro- 
feature selection is made, the possible values for that feature motion Analysis; and Forecast Performance Evaluation. 
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Each of these activities requires a slightly different User Customer Table 

Interface lo accomphsh the task at hand. Therefore, a Since BU forecasting is a customer-driven operation, the 

different screen is used for each, although tbey will share loptnost table displays the customer tree for the selected 

many common elements, tools, and procedures. Within the domain. Only those domain entries which are strictly 
DM Frame, any number of activities can be operative, 5 customer-oriented are shown in the customer table. Entries 

however, the user may view only one screen at a time. The are displayed in an outline form as they were defined in the 

user may change the view from one screen to another domain. The first column in the table lists the names of 

without losing any data or configuration information asso- customer groups or customers, while the remaining columns 

ciated with each screen. contain the total sales data for that customer. A split line in 

All DM activities take place within the same data domain, lO the table divides historical and Forecast Data 146. The time 

although different Data Domains may be active in other spans for historical and Forecast Data 146 can be specified 

Frames 16 of the DSS 10. The user can select a new data by the user. 

domain for the DM activities at any time using the standard Customer groups may be expanded or collapsed by 

DSS 10 data domain selection dialog box. double clicking Iheir names in the Customer column entry. 

There are several desirable features common to each of i5 Product Table 

the DM screens. Regardless of the area in which the user is The bottom table displays all products carried by the 

working, the user is able to perform the following opera- selected customer (group). Sales data for each product 

tions: save and retrieve DM configuration information; save shown is presented in outline form, which may be expanded 

and retrieve data from the DSS Database 12; save and or collapsed by double clicking on a product name. The 
retrieve DM data as a scenario; display point-of-sales or 20 entries beneath each product include actual orders, forward 

shipment data (where applicable); specify limits on data orders, and orientation orders. As with the Customer Table, 

time series; ^ecify the resolution of data time series (yearly, the table is ^lit to show both historical and Forecast Data 

monthly, weekly); display data as absolute values, or as 146. The user may specify the position in the time scries for 

percentages of some total values; display data in tabular or the historical and Forecast Data 146. Promotion periods are 
graphical form; clear, cut, copy, paste data series within the 25 highlighted on the display. 

DSS 10 and Windows environment; and apply functions to Total Columns 

data in a "scratch" or work area. On the right side of the Product table is three columns 

Work Area Pop-Dp Screen which can display a selection of user-defined totals from the 

In addition to the dedicated screens, a pop-up window is following choices: YTD Year to date; YTG Year to go; 

available lo act as a scratch or work area. Data series can be YTDL Year to date last year; YTDB Year to date budget; 

cut, copied, and pasted lo and from this window and other YTGB Year to go budget; and L12M Last 12 months. 

DSS windows, as well as other Windows applications. Users General Features 

can use this window to process and analyze data. Promotions periods are displayed highlighted. The impact 

The following sections describe each of the DM screens of promoted verses unpromoted sales can be displayed 

in more detail. separately in drop-off celts. The mix percentage can be used 

Demand Characterization to disaggregate a forecast generated at the aggregated level 

This area of the demand characterization screen enables of the customer or customer group, 

the user lo visualize the selected domain in outline form. The Disaggregation can also be done based on the total for the 

user can then select one or more data streams at any level of year and some user defined seasonality factors when the 

aggregation, and by using the option menu, specify the type menu option "Disaggregate Total year" is chosen. Time 

of data to be displayed: sales history, sales characteristics, or series of user defined "leading indicators" can be displayed 

Market Data 140. The Market Data 140 may not be always for reference and forecasting purposes, 

available at the same resolution as the firm's Demand Top-Down Forecast 

History Data 136. Therefore, special "market Data ^ 5^ expected, the Top-Down (TO) forecast 

Domains" are created to facilitate access to the Market Data screen (see FIG. 57) is similar to the Bottom-Up Forecast 

A****- screen, except that the interface is arranged for product- 

On the right hand side of the grid the user can choose driven forecast operations. On the TD screen the Product 

between a set of summary statistics to be displayed: YTD (able appears at the top. while the Customer table appears 

Year to date; YTG Year to go; riDL Year to date last year; below it. Data display options and forecasting tools for TD 

YTDB Year to date budget; YTGB Year to go budget; and operations are accessed from the TO screen menu and 

L12M Last 12 months. subsequent dialog boxes. 

Several analysis tools are available: Trend, Moving Product Table 

average. Pattern changes, Parelo analysis, and correlation -phe Product table displays the list of products from the 

between products. The output of these analyses can be selected domain. Only those entries which arc strictly 

displayed in table or in graph. product-oriented are shown in this table, and are displayed 

Sales Characteristics Screen iri an outline form as they were defined in the domain. The 

A set of Sales Characteristics can be computed and first column in the table lists the names of product groups or 

displayed in a special table: average level of demand, trend, individual products, while the remaining columns contain 
volatility, and lumpincss. Accessing this table can be done ^ the sales data for that product aggregated at the appropriate 

through the menu under the option entry level. A split line in the table divides historical and Forecast 

Bottom-Up Forecast , Data 146. 

The Bottom-Up (BU) forecast screen (see FIG. 56) con- ITien the user selects a product group or product from the 

tains a Customer Table and a Product Table which have Product table, the list of customers carrying the product(s) is 
several configurable columns and data display options. BU 6S displayed in the Customer table as described below. Product 

operations and functions are accessed from lite BU screen groujjs may be expanded or cx)!lapsed by double clicking 

menu and subsequent dialog boxes. their names in the Product column entry. 
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Customer Table 

The bottom table displays all customers who carry any of 
the products selected in the Product table. If a customer 
carries all of the selected products, it is displayed in a 
focused foot, otherwise it is shown in Dormal font. Sales data 
for each customer is shown. The entries beneath each 
product include actual orders, forward orders, and orienta- 
tion orders. As with the Product (able, the customer table is 
split to show both historical and Forecast Data 146. The user 
may specify the position in the time series for the historical 
and Forecast Data 146. Promotion periods are highlighted 
on the display. 
Total Columns 

On the right side of the Customer table are three columns 
which can display a selection of user-defined totals from the 
following choices: YTD Year to date; YTG Year to go; 
YTDL Year to date last year; YTDB Year to dale budget; 
YTGB Year to go budget; and L12M Last 12 months. 
General Features 

Promotion periods are displayed highlighted. The impact 
of promoted verses unpromoted sales can be displayed 
separately in drop-olf cells, llie mix percentage can be used 
10 disaggregate a forecast generated at the aggregated level 
of the customer or customer group. 

Disaggregation can also be done based on the total for the 
year and some user defined seasonality factors when the 
menu option "Disaggregate Total Year" is chosen. Time 
series of user defined "leading indicators" can be displayed 
for reference and forecasting purposes. 
Sales Promotion Analysis 

The User Interface that supports Sales Promotion Analy- 
sis is built around the promotion calendar. The promotion 
calendar shows the list of all the past and planned promo- 
tions for the set of products and customers defined by the 
selected domain. 

For each promotion the following is displayed in the 
promotion calendar: starting date of the promotion; end date 
of the promotion; promotion type; promotion class; product 
being promoted; customers supporting the promotions; pro- 
motion intensity; and impact of the promotion. 

When the user clicks on the promotion calendar button on 
the toolbar, the promotion calendar Main Display Window is 
displayed (see RG. 58). 

The user can select one or several promotions in the 
promotion calendar. For these promotions the user can 
perform the operations discussed below. Display shipment 
and POS Data 12H in table formats similar to the one used 
in BU and TD forecasts. Compute the promotion impact for 
past promotions. Estimate the impact of future promotions. 
Display graphically the impact of the promotions on sales. 

If the user wishes to view the customer-product tuple 
(domain) that promotions are displayed for, or wishes to 
limit the promotions shown by choosing what Promotion 
Type, Promotion Class and Promotion Intensity he wishes to 
analyze, the Promotion Selection Wizard may be invoked. 
The user selecLs the customer-product pairs thai analysis is 
to take place on and can limit the selection by choosing what 
Promotion Type, Promotion Class and Promotion Intensity 
he wishes to analyze. When the OK button is clicked, the 
Promotion Calendar dialog box is populated with all pro- 
motions that match the selection criteria (See FIG. 59). 
PSI Frame 

The PSI main screen is a work area where the user can 
experiment with different Production, Inventory and Sales 
figures and see the effects caused by these changes to 
eventually converge to the most desirable PSI plan 190, Tlic 
Main PSI Screen (see FIG. 61) initially shows the 
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Production, Inventory and Sales for all of the products in the 
user selected domain. The figures for all of the products are 
aggregated together and shown. The user may also select 
any individual product in the aggregation and show the 

5 numbers for this product alone. This can be done by choos- 
ing the desired product number from the Product selection 
combo box located near the top left of the screen. The first 
choice in the combo box is always All Producb to allow the 
aggregation of all products to be shown. The user may 
change the products being analyzed by selecting a new set 
of products from all available products. This may be done by 
selecting a new domain. 

Directly following the Production (P), Inventory (1) and 
Sales (S) lines are Temporary P, S and I lines (see FIG. 60). 
This is a work area where the user may copy and experiment 
with the real P, S or 1 figures and modify them to create new 
Scenarios 78. Copy and Paste are enabled on this form so the 
user may copy the original numbers to the work areas. The 
user may also copy a lime series from another part of the 
DSS 10 or a separate application to the temporary lines 

20 through copy and paste. Lastly, the user may load data from 
a saved scenario to the temporary lines on the form. The 
individual cells that comprise the temporary work area may 
be manually edited by the user by clicking on the desired cell 
and changing the value in the cell. 

25 Also present on the work area of the form are Top-Down, 
Bottom Up, Customer demand information, a Top-Down 
minus Bottom Up (TD-BU) and Top-Down minus Sales 
(TD-S) lines. These lines give the user different and useful 
views into the planning data under analysis. These lines are 

30 calculated based on the values in the temporary P, S and I 
hnes of the form. 

The last column displayed on the screen is a sum of the 
data displayed on the screen for the current year. This 
column remains on the screen and does not scroll left to right 

35 as other columns are being scrolled horizontally. The titles 
of the various horizontal lines of data also does not scroll, 
but the data series may be scrolled forward or backward 
through time. The month and year associated with the data 
are displayed immediately above the working area of the 

40 screen. 

PSI Reconciliation 

While working with the data in the temporary P, I and S 
lines, the user may want to make sure the three lines are 
always consistent. 'ITiis may be accomplished by selecting 

45 PSI Reconciliation on the Options menu (see FIG. 62). 

When selected, a check mark will appear next to this 
menu choice and the PSI screen will reconcile all data input 
by the user. PSI Reconciliation 170 functions by updating 
one line of data based on a new value input into a different 

50 line. The user has control over which line gets updated by 
setting the PSI reconciliation order. 

The user sets the PSI reconciliation order by choosing PSI 
Reconciliation Order from the Options Menu (sec FIG. 61). 
This will open the PSI Reconciliation Dialog Box (see FIG. 

55 62). From this window the user can choose which line(P, S 
or I) is updated when the selected line is modified by the 
user. In the example shown, the I Line would be updated 
when the Production line is changed. 
Capacity Checking 

60 While working with the Production, Inventory and Sales 
figures, the user may wish to check the capacity of the 
existing production resources to determine if (he current 
plan is feasible. 'Iliis is known as capacity checking. This 
can be accessed by clicking the Check Capacity button on 

55 the Options menu group on the main PSI screen. 'ITie main 
capacity checking dialog box will then be displayed (see 
ITG. 63). 
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The Options tab allows the user to select the desired plant 
location and the feature of interest and pick the existing lines 
that may produce the products with the selected feature. The 
user may remove selected products from the list of products 
that he wishes to analyze. The user may select the Produc- 
tion resources he wishes to analyze from the list of available 
production resources. The user may select the key compo- 
nents of the products that he wishes to analyze. The user may 
change the options before performing capacity checking to 
restrict the scope of the Model Engine 20, and after checking 
capacity for viewing purposes. 

The results tab shows (see FIG. 64) the results of the 
capacity checking. For alt products selected, a production 
plan is displayed, and at the top of the screen, whether or not 
the plan is feasible is indicated. The capacity checking may 
be viewed product by product or by product group. 

The production resource tab (see FIG. 65) is used to show 
the available capacity for the selected line for two months. 
If this line has enough capacity, it is indicated at the top of 
the screen to be feasible. The user can also see how much 
capacity remains or how much more is needed by looking at 
the Over and Under lines. 

The Key Components tab (see RG. 66) is used to view the 
important componetits required to assemble a final product 
and check whether, using the current figures, there is sufE- 
cient quantity of these components. If too much production 
requiring one key component is scheduled and the part will 
run out, then the key component is indicated as infeasible. 

The Bill of Material tab (see FIG. 67) allows the user to 
see which components are used in which products. By 
selecting specific components, the user can see which prod- 
ucts use the components. 

The Alternative Components tab (see FIG. 68) allows the 
user to see components that may be substituted for other 
components during production. The user may view the list in 
two ways. By selecting Product, the user can see the 
components that are used to assemble the product and any 
alternative for the components. By selecting Component, the 
user can see specific components and any alternative parts 
that exist. 

'ITie Resource Requirement tab (see FIG. 69) allows the 
user to see the projected production plan for a selected 
assembly line and product feature type. ITie user may view 
this by selecting a line then a product group that may be 
produced on the line or by selecting a product group then a 
line and viewing the schedule for the selected product 
groups. 

Key Components Selection 

To analyze production of a product the user must work 
with the components that are used to build the product. The 
user does not need to exhaustively analyze all components, 
but just a subset of the components. These arc the major 
components of the product and are usually referred to as the 
Key Components. Which components are considered key 
may change over time, so the user must have a way of 55 
selecting the current key components. This task is performed 
by using the Key Component Selection dialog box (see RG. 
70). 

The Key Components column of the main display area 
indicates whether the component is a key component. All 6o 
key components are also shown in a list at the right of the 
dialog box. The user may change the setting of a component 
or multiple components by selecting them and clicking the 
Key Components button to set them to be key or Not Key 
Components to make the components not key. The user may 65 
sort the components so all key cximponents arc shown at the 
lop of the list by clicking the Sort Components button. 



The second column of the main display area is a total for 
a selected range of months. The default is for the entire year. 
The user may select a different range by using the mouse to 
highlight a range of months and clicking the Ordered Based 
5 on Months button. This will rctotal the column for the 
selected range of months and change the caption for the 
column to indicate the month range selected. It will also sort 
the list of components to show the products from greatest 
availability over usage to least availability over usage over 
10 the selected time period. 

The many features and advantages of the invention are 
apparent from the detailed specification and, thus, it is 
intended by the appended claims to cover all such featxires 
and advantages of the invention which fall within the true 
15 spirit and scope of the invention. Further, since numerous 
modifications and changes will readily occur to those skilled 
in the art, it is not desired to limit the invention to the exact 
construction and operation illustrated and described, and 
accordingly all suitable modifications and equivalents may 
20 be resorted to, falling within the scope of the invention. 
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[database Specifics tions for Manufacturing Supply 
Chain 

Tlie following are the specifications of the data tables for 
the manufacturtnp supply chain. 



Field Identifier 



Field Type l)escripiion 



35 



40 



Aggregate Production Plan Dala 

Data related lo the aggrc^tc production plan for the product 
and resource identified tn the APP header 

APPHcadcrlD Ijong APP Header identifier {sec 

aggregate prodt^on plan 
Header table). 

TuncPciiod Datc/Hmc Ttmc period numt>cr 

SupplyOrderlD Tfexi Supply order pegged to (if 

available) 

Quantity Double Kumbcr of units of production 

PropQsedChangc Double Recommended cliangc in the 

planned quatUily (to store 
changes between rcgciKration of 
APPS) 



Aggregate Production Plan Header 
Header file for defining the Product X Resource X Time 
resolutions and values for various aggregate production plans. 



APPHcederiD 
APPID 



Rcsou tec Resol utio n 



SO 



Produa Reso luti o n 



ProdualD 



TimeResolution 



Calendar ID 
DalcCreated 



Scenario Data 
SccnarioCounter 



APP Data Scries Identifier 
IdcDtiHer for an aggregate 
production plan 
Resource Resolution; R- 
Rcsource, 0-Group. N-Node 
Resource associated with an 
aggregate prodturtion plan 
Product Resolution: P- 
Product, G-Group 
Product associated with an 
aggregate production plan 
D for day, W for week; F 
for bi-weekly; M For 
monthly: B for bi-monthly; 
Q for quarterly; and A for 
annually. 

Pegged to a predefined 
calendar 

Dale/Time Date when Uie aggregate 

production plan was created 
(based on the time 
tesolution) 

Yes if it is scenario data. 
No otherwise 
Number of scenarios in 
Which thi.^ header 
participates 



Long 
Ttxt 

Text 

Text 

TbH 

Text 

Thxl 



Integer 



Boolean 



B>te 
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Appendix A 

Database Speclficaiions for Manufacturing Supply 
Chain 

The following are the specifications of the data Ubles for 
the manuFncturing supply chain. 



Fieid Identifier 



Field Type Description 



Budget Data 

Data for budgeted costs and reveaties 



Long Budget header identifier 

Etatc/Tlrac Time period number 

Double 'Hirget revenue in $ 

Etouble Allocated cost in $ 



BudgetlleadetlD 
Time Period 
Tiigpt Revenue 
BudgctCost 
Budget Header 

Header file for deftning the Product X Resource X Customer X 
Time resolutions (not all need be present) for various budgets 



BudgetHeaderlD 

Product Rcso lutio D 
ProductlD 

CustomerResolution 



CustomerlD 
ResouroeResolutio n 
Resource ID 
luneResoIution 

CalendarlD 
DateCreatcd 
SccnarioData 
ScenarioCounter 



Long 

Ttxt 
TbKt 
Text 



Text 
Ttxt 
Text 
Ttxt 

Long 

Date/Time 

Boolean 

Byte 



Identifier for the 
BudgetHeader 



Customer Resolution: C for 
Customer, G for Customer 
Group, A for all 
Customer associated with the 
budget 

Resource Resolution: R- 
Rcsource, O-Group, N-Node 
Resource associated with the 
budget 

W for week; F for bi-wcekly; M 
for moothly, B for bi monthly; 
0 for quarterly; a ad A for 
annually 

Pegged to a predefii>ed 
calendar 

Date of creation for this 
header 

Yes if it is scenario data. No 
otherwise 

Kumber of scenarios in which 
this header participates 



Calendar 

Predefined calendars to peg the various data to 



CalendarlD 

Date 

DayNo 



Bi\McekNo 



MonthNo 



BiMonthNo 



QuflrtcrNo 



Holidaylodicator 



Component 
Data related to components of the producu 



Long Unique calendar identifier 

Date/Fime Julian Calendar Date 

Double Unique number for a day in the 

calendar year (typically 1 

through J65) 
Double Unique number for a week in 

the calendar year (typically 1 

through 52) 
Double Unique number for a bi-wcck in 

the calendar year (typically 1 

through 26) 
Double Unqiue Dumber for a month in 

the calendar year (t>pica!ly ] 

through 12) 
E)ouble Unique number for a bi-month 

in the calendar year 

(typically 1 through 6) 
Double Unique number for a quarter in 

the calendar year (typically 1 

through 4). 
Boolean To indicate whether it is a 

holiday or not 



Component! D 



CotnponentiName 
MinPockOunntity 
PhpicalParamctcr 



Tfcxt Component [D in the planning 

BOM from corporate master 
(e.g. 3317307) 
Ttxi Name of the component 

[)oublB Minimum pack quantity 
Text Phj'sical dimensions for the 

component 
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Database Specifications for Manufacturing Supply 
Chain 

The following are the specifications of the data tables for 
the manufacturing supply chmn . 



Field Identifier 



Field Type Description 



10 CompCategory 

PackagingI nstructio n 



Text S for Off-the-Shelf; C for 

Customized 
Text Special packaging 

requirements 
Component Accommodation Matrix 
Equivalence of the key components to produce diffetenl 
15 pro**"*^- 



ProdualD 

PrimaryCo mponentlD 

AlternativeCotnponentlD 

Quantity 



Text SKU number 

Tfext Primary component 

identifier 

Text Alternative component 

identifier 

Text Number of componenta of 

the Alternative Component 
that can substitute for 
one unit of the Primary 
component to product 
ProductlD 

25 Component Requirement Data 

Data related to tequircmenis for the component ideiaified in 
the header 



CompRcqHeaderlD 

30 TmiePeriod 
Quantity 

Proposed Change 



Long Identifier for the component 

requirement header 
Date/Time Time period number 
Double Number of units during the 

time period 
Double Proposed Change in requiied 
quantity 



Component Requirement Header 
^5 Header file defining the Component X Time resolutions and 
values for various component requirement data 



CompReqHeaderlD 
ComponenllD 



40 



BOMID 
DaleCrented 



Time Resolution 



Long 
Text 



Text 

Date/Time 



CalendarlD 



50 

APPID 

Scenario Data 
55 ScenarioCounter 



Integer 
Itxt 

Boolean 
B>-te 



Component Supplier 

Data for the supplier of components 



Component Requirement 
Heatkr Identifier 
Component associated with 
an components 
requirements plan 
Unique identifier for BOM 
Date when the component 
requirements plan was 
created (based bn the 
lime resolution) 
D for day, W for week; F 
for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for quarteriy; 
and A for annually 
Pegged to a predefined 
calendar 

Pegged to an aggregate 
production plan (if 
wananted) 
Yes if it is scenario 
data. No otherwise 
Number of scenarios in 
which this header 
participates 



60 



CompSupplierlD 


Text 


Unique identifier for the 






component supplier 


SupplierName 


Text 


Name of tlie component 






supplier 


FaymentTerms 


Text 


Example: Nct-60 


SljeetAddress 


Text 


Street Address 


State ID 


Text 


Name of the State 


PoiLilCodc 


Text 


Postal code 


Country 


Text 


Name of the country 
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Appendix A 

Database Specifications for Manufacturing Supply 
Chain 

The following are Ihe specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



CoirpSupplyNodelD Tfexl 

CompSupplierlD Tbxt 

AvgSupplyLeadtime Doubl 

SupplyContraclID Text 

PteferredCarricr Text 

Cuslome* 

Data for individual customers 

CustomerlD Ttxt 

SbipToLocation Tbxt 

DemandNodelD Text 

CustomcfNamc Text 

Address Text 

Stale Text 

PoslalCode Text 

Country Text 

Customei Group 

Data For customer groups 

CustomciGroupID Ttxt 

CustomciGroupName Tfext 

CuslomeiGroup'Rig 'Itxl 



Comment Text 
SccnarioGroup Boolean 



Unique identifier for the 
supply node (e.g., 
CVTCabinetNodel) 
Idcntifici of the 
component supplier 
Average lead time to 
supply the componcnls 
(from the time of order) 
ID for the Supply 
Contract (Sec Cotnponcal 
Supply Contract Table) 
Preferred transportation 
carrier for shipping 
(e.g„ FEDEX) 



Customer from corporate 
customer master (e.g. 
BcslP) 

Specific customer 
location, (e.g. DCl) 
The demand node (his 
customer is associated 
with 

Mamc of the customer 
Street address 
Name of the state 
Postal code (Zipcode for 
domestic) 

Name of the Country 



Identifier for the 
customer group 
I?cscripti%e name of 
customer group (e.g., 
Stereo CTV) 

Organizational entity who 
defined the build 
criteria for the customer 
group (e.g. Marketing) 

yes if this is scenario 
group; No otherwise 
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Database Specifications for Manufacturiitg Supply 
Chain 

The following are the specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



Component Supply Contract 

Data associated with the component supply contrac t 

SupplyContraclID Ttxt Identifier for the supply 

contract 

ContractDate Tfext Date of the contract 

NomialLeadTune Text Negotiated nominal lead 

time for a defined 
average quantity 
UnitPrice Double Negotiated unit price of 

the component 

OtyDtacount Double Percentage of discount if 

the quantity is above 
QtyforDiscount 

QtyforDiscount Double Minimum size of the Order 

to qualify for the 
quantity discount 

MinOrdeiQty Double Minimum quantity that can 

be ordered from the 
supplier 

Component Supply Node 

Data associated with the component supply node 



10 Customer Group Definition 

Tabic that identifies the parent -child relationship between 
customer groups and customers 



CustomcfOroupID 
J 5 CustomerlD 



Text 
Text 



Customer Orders 

Data for actual customer orders 



Name of the customer 
group 

Name of the member 
customer (or customer 
group) 



20 



CustomerOrderld 



Text 



LineitcmID 
CustomerOrdciRefNo 
25 CuitomciID 
ShipToLocation 



30 



ProdualD 



CalendarlD 
Time Resolution 



Text 

Ttxt 

Text 

Text 

Itxt 

Long 
Text 



ID for the actual 
customer order (e.g. pcec 
type 1 orders) 
Line item within the 
order 

Customer's purchase order 
identifier 

Customer identified with 
the order 

Ship to location for the 
order 

Product associated with 
the order 

Pegged to a calendar 
D for day; W for week; F 
for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for quarteriy; 
and A for annually. 
Date/Time [expressed in terms of the 
calendar and time 
resolution 
Date/Time Eixpiessed in terms of the 
calendar and time 
resolution 
Date/^rime Expressed in term of the 
calendar and time 
resolution 
fiate^'ime Expressed in terms of the 
calendar and time 
resolution 
Date/rime Expressed in terms of the 
calendar and time 
resolution 

Quantity of the order 
Such as value added 
services associated vnth 
the order 

50 Customer Product Resource Relationship Matrix 

Thble that identifies the Customers, Product and Resources 
that have pairwise relationships 



35 OrderEntryDate 



RequestedDate 



40 



45 



DueDatc 



ShipDatc 



Delivery Date 



Quantity 
Comments 



Double 
Memo 



55 



60 



PioduaResoIution 

PiodualD 
QistomciRcsolution 

CustomerlD 



Datatj-pcID 
^5 ResoutceRcsolution 



Tbxt Resolution of the 

product; P for product, G 
for product group 

Tbxt Identifier for the 

product or product group 

Text Resolution of the 

cuslamcr: C for 
customer, G for customer 
group 

Text Identifier for the 

customer or customer 
group. 

Text PCS Data, Top Down 

Forecast, Bottom Up 
Forecast 

Text Resolution of the 

resource: R for 
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Appendix A 

Database Specifications for Manufacturing Supply 
Chain 

The following are tbe specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Descripti on 



resource, G for resource 
group 

RcsourcelD Text Idcniifler for the 

resource or resource 
group 

Demand History Data 

Data for tbe demand history for the product defined in the 
header 



DemandHistHeaderl D 



Long Identifier for a demand 

history 

Date/Timc Tune period number 
LjODg I>emaod Quantity 



TimcPeriod 
Demand Qty 

Demand History Header 
Header file defining tbe Customer X Product X Time resolutions 
& values for various demand histories 



Demand HIstHeaderl D 
P roduc t Eleso lutio 0 

PtoductCD 
CustomerResolulion 

Customer[D 
HmeResolution 

CalendarlD 
DateCreated 
ScenarioData 
ScenarioCountet 



Long 
Tcjct 

Tfext 
Text 



Text 
Text 

Integer 
Date/Time 
Boolean 
Byte 



Demand Node 

Data associated with the demand node 



DemandNodefD 



DemandNodeNamc 



Ttxt 



Ttxt 



Identifier for a demand 

history header 

P for product; G for 

product Group; A for all 

productJi 

Product associnted with 

demand history 

S for customer ship to; C 

for customer; G for 

customer group; M for 

market; A for all 

customers 

Customer associated with 
demand history 
D for day, W for week; F 
for bi-wcekJy; M for 
monthly; B for bi- 
monthly; Q for quarterly: 
and A for annually. 
Pegged to a predefined 
calendar 

Date of creation of the 
header 

Yes if it is scenario 
data, No otherwise 
Number of scenarios in 
which this header 
participates 



Unique identifier for the 
demand node (e.g., SEARS 
or a region) from the 
enterprise point of view 
Description of demand 
node 



Comment 
Demand Orientation Data 

Data associated with the demand orientation for the product 
identified in the header 



OricntationHeaderlD 



Long 



Orientation Header 
Identifier 
Date/Time Date when the order is 

projected as required 
Double Quantity of the 
orienution 

Demand Orientation Header 

Header file defining the Customer X Product X Time resolutions 
and values for \'ariaus demand oriemations 



TunePeriod 



Quantity 



OricntationHeaderlD 



Lx5ng 



Orientation Header 
IdcnlificT 



10 



40 



50 



60 



Appendix A 

Database Speciftcations for Maniifacniring Si^ly 
Chain 

Tbe following arc the specifications of the data tables for 
the manufacUirinR supply chain. 



Field Identifier 



Field type Description 



CustomerRcsolutton 



j5 CustomerlD 

Product Re solution 



ProductlD 



20 



TimeRcsolution 



25 

CalendarlD 
DatcCrcaled 

Scenario Data 

50 ScenarioCountcr 



Tfeit S for cusiomct ship to; 

C for oiBtomer; G for 

customer group; M for 

market; A for all 

customers 
Ttxt Customer identified with 

the place keeping order 
Tfext P for product; G for 

product group; A for all 

products 

Text Product associated with 

the orientation order 

Text D for day; W for week; F 

for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for 
quarterly; and A for 
annually 

Long Pegged to a calendar 

DateAime Dale the header was 
created 

Boolean Yes if it is scenario 
data. No otherwise 

Byte Number of scenarios in 

which this header 
participates 



Domain 

User and domain description for various domains 



The name of the domain 
The owner of the domain 



DomainlD Long 
EtomainNamc Ttxt 
DomainOwner Text 
Domain Definiiion 

Domain definitions in terms of product, customer and resource 
groups 



DomainID 

Prod uctReso lutio n 



Product 

CusiomerKesolution 



Long 
Text 



Text 
Text 



Ttxt 



P for product; G for 
Product Group; A for ail 
products 

C for customer; G for 
customer group; M for 
market; A for all 
customers 



Customer 
Feature Choices 

Tbe various unique values for the diiTerent product features- 
generated on a batch basis 



ProductType 



55 



Feature 
Choice 



Text 



Integer 
Text 



The type of the Product 
that these features 
belong to 

Feature of the Product 
Name of tbe Feature 
possibility 



Forecast Data 

Data associated with forecasts for the prodixl' customers 
identified in the forecast header 



FcstlleaderlD 

Time Period 
ForCCTSlVfelue 
65 FotecastCV 



Long Pegged to the Forecast 

Header Table 
Date/Time Time period number 
Double Forecast data value 
I!>oublc CoeScicnt of variation 

of forecast 
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Database Specifications for Manufacturing Supply 
Chain 

The following are the specifications of the data tables for 
the manufacturing supply chain. 



-continued 

Appendix A 

Database Specifications for Manufacturing Supply 
Cbain 

The following are the specifications of the data tables for 
the manufacturing supply chain. 



Field [denlifier 



Field Type Description 



Field Identifier 



field Type Description 



Forecast Header 

Header file defining the Qistomcf X Product X Time resolutions 
& values for various forecasts 



10 BaclcOrderlnventory 
InTransit 

Reservedlnveniory 



FcstHcadcrfD 
P loduct Reso lutioo 

ProduclID 
CustomerResolution 

CustomerlD 
Time Resolution 



CalendarlD 
DateCreated 

ForecastType 

Fo recastAssumpttons 

ForccastOwner 
Scenario Data 

ScenarioCounter 



Ixing Forecast Header 

Identifier 
Text P for Product, G for 

loduct Group, A for all 

Products 

Text Product awociated with 

forecast 

Ttxi S for Ship-to, C for 

Custoncier, G for Customer 

Group, A for all 

Customers 
Text Customer associated with 

forecast. 

Ttxt D for day; W for week; F 

for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for 
quarterly; and A for 
annually. 

tntegcr Pegged to a predefined 
calendar 

Date/Tinie Date when the forecast 
was created (based on 
the lime resolution^ 

Text B for bottom-up; T for 

top-down 

Memo Assumptions associated 
wiih the forecast 

Text Author of the forecast 

Boolean Yes if it is a scenario 
data; No otherwise 

Byte Number of scenarios in 

which this header 



Double Back-ordered inventory 
Double In-transit quantity 
Double Reserved inventory on- 
hand but available for 
allocation onJy in case 
of emergency 

j5 Inventory Header 

Header file defining the item (Product oi Component) X Time & 
and values for various inventory data 



20 



25 



participates 

Freight Rate 

Table that summarizes the various freight rates 



Invcnlo ryHcaderlD 
InventoryNodelD 

InventoryControlID 
ItemID 

ItemResolutioQ 
Time Resolution 



30 

CatcndarlD 
MinlnvcntoryLcvci 
35 Max! nven to ry Level 
DaleCreated 
Scenario Da [a 
ScenarioCounter 

40 



Long Inventory Data Scries 

Identifier 
Text Identifier for an 

inventory logical 

warehouse 
Text Identifier for inventory 

control parameters 
Ttxt Product [tern ID 
Tbxt Item Resolution: C for 

Component, P for Product, 

G for Product Group and A 

for All 

Text D for day; W for week; F 

for bi-weekly; M for 
monthly; D for bi- 
monthly; Q for quarterly; 
and A for annually. 

Integer Pegged to a predefined 
calendar 

Double Minimum inventory level 

for the item 
tJoubte Maximum inventory level 

for the item 
Date/Time Date the inventory header 

was created 
[}oolcaD Yes if it is scenario 
data. No otherwise 
Byte Number of scenarios in 

which this header 
participates 











Inventory Node 






FreighlRatcTablelD 


Text 


Freight rate tabic 




Data associated with the inventory node 








idcntiAcr 










FreightDescription 


Text 


Description of the rate 


45 


InventoryNodelD 


Text 


Unique identifier for the 




table 






inventory node (e.g., 


MaxWeight 


Double 


Maximum weight limit 








AtdcnWarchouse2) 




(e.g. truck capacity) 




FacililylD 


Text 


Physical Facility 


MaxCubc 


Double 


Maximum volume limit 








identifier 


WeightCategory 


Itxl 


e.g. 0-100 lb, 100-500 lb, 
etc. 




InvcntoryCategory 


Tbxi 


Component or FO- 
ISntcrprisc 


MileageCfttegory 


Tfext 


e.g. less than 100 miles, 


SO 


IrrventoiyEchclon 


Double 


1 or 2 




less than 500 miles, etc. 




InvenioryNodeNamc 


Itxt 


Name for the inventory 


MinimumCharge 


Double 


Minimum charge associated 








node 






with a trip 




Service l^vel 


Double 


Service level for the 


StdCost 


Double 


e.g. $ per hundred weight 








inventory node 






charge for LTL and $/miIe 




Address 


Text 


Address for the inventory 






for TL 


55 






node 


EconoiTiyCosi 


Double 


e.g. for fedcx economy 
rate 


StotageCapacity 


Double 


Ph>'sical storage capacity 
of the inventory node (in 


PremiumCost 


Double 


e.g. for fedcx next day 
service 




Inventory Parameters 




cubic feel for example) 


Inventory Data 








Data for the inventory control parameters 


Inventory data for items (products or 


components) identified 


60 








in the header 






InventoryControlID 


Text 


Identifier for inventory 



InventoryHeade rl D 

nmePeriod 
OnHandlnvcntory 

OnOrderlnvcniory 



Ijong Inventory Data Scries 

Identifier 
Da[e/Time Time period number 
Double On-hand available 

inventory for allocation 
Double On-order inventory 



SafelyStockFactor 
TargelServicc Level 
65 Policy lype 



Assume inventory planning 
" inventory control 
Double Safety stock factor 
Double 'Ihrgel service level 
Text Policy type: 

SS, Min/Max. OR. etc. 
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Appcadix A 

Database SpeciAcaiions for Manufaciuriiig Supply 
Chain 

The following are ihe specifications of [he data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



Mintnveniory Factor 



MaxI nve nCO ry Facto r 



M in O ide iQt y Factor 

CarryChargc Facto r 
OrderCha rgeFactoi 
InventoryClftss 
Replenish mcnt 
Frequency 



Double 



Double 



Double 

Double 
Double 
Text 
Double 



Minimum inventory factor 
(e.g., in tetms of weeks 
of salc5) 

Maximum inventory factory 
(eg., in terms of weeks 
of sales) 

Minimum order quantity 
factor 

Carrying cost (actor 
Ordering cost factor 
Envenlory clawification 
Frequency of 
replenishment w.r.t. the 
time resolution in the 
header 



Market Data 

Data for the market defined in the header 



MarketlleadcrlD 



Time Period 
MarkelShare 

Consumer Demand 
AveragcSellingPricc 



Long ID fo( market header 
(sec Maikct Header 
table) 

Date^lme Time period 

Double Percentage of share held 

by the company 
Double Total demand quantity 
Currency Average Unit Price of 

the produa 
Double Forecasted demand 



Demand Forecast 
Market Header 

Header for defining the market (Product X Customer 
resolutions) and values 



MarkctHeaderlD 

MarkctDctinitionID 

MarkctNamc 

DataScope 

DataSourccID 
TuneResolutioo 

CalendariD 
Product Resolution 
ProductlD 
CustomerResolution 
CustomerlD 
DaleCiealed 
Scenario I>ata 
SccoarioCOunter 



Long Identifier for the market 
header 

Text Unique identifier for a 

market (e.g., FTV-S) 

Text Maikct Description (e.g. 

Projection TV in Selling 
floor) 

Text Suitable tag: Brand name 

(e.g., Sony) or industry- 
wide 

Text Source of market data 

(c.g, NIELSEN) 

Tfext D for day, W for week; F 

for bi-weekly; M for 
monthly; B for bi- 
monthly;- 0 for quarterly; 
and A for annually. 

Integer Pegged to a predefined 
calendar 

Text P-Product, PG-ProducI 

Group, A-AJI products 

Text IdcntiScr for the 

product 

Text C-Customer, CG-Oistomer 

Croup, A-All 
Text Identifier for the 

customer 
Date/Time Date the header was 

created 

Boolean Yes tf it is scenario 
data; No otherwise 

Byte Number of scenarios in 

which this header 
participates 
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-continued 

Appendix A 

Database Specifications for Manufacturing Supply 
Chain 

The following are the specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



10 Material Delivery Schedule Data 

Material Delivery Schedule for the Component identified in the 
header 



MDSHeaderlD Long Identifier for the 

Material Delivery 
Schedule Header 
DclivcryDatc DateAimc Matwial Delivery Date 

Quantity Double Number of units of 

material delivery 

Material Delivery Schedule Header 

Header file defining the Ct)raponent X Supplier X Time 

resolutions & values for various material delivery'schedules 



MDSHeaderlD 



ComponentSupplyNod 
elD 

25 SupplierlD 



Time Resolution 

30 

CalendartD 
DaleCreated 

35 

ScenarioData 
ScenarioCounter 



40 



Planning BOM 
Imploded Bill of Material used for Planning 



Long Identifier for the 
Material Delivery 
Schedule Header 

Tfext Identifier for component 

supply node 

Text Supplier associated with 

a Material Delivery 
Schedule 

Ttxt D for day; W for week; F 

for bi-weekly, M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 

Integer Pegged to a predefined 
calendar 

Date/Iune Date when a Material 
Delivery Schedule was 
created (based on 
consistent time units) 

Boolean Yes if it is scenario 
data, No otherwise 

Byte Number of scenarios in 

which this header 
participates 



BOMID 



45 



CtomponcntlD 

PtoductID 
50 Quantity 



Tfext 



Text 
Double 



Unique identifier for the 
planning BOM (defined 
external to the DSS 
database) 

Unique component 

identifier 

SKU number 

Number of components used 
in SKU 



POS Data 

Point of Sale data for the customer-produds identified in the 
header 



55 POSHeaderiD 
Time Period 



60 



SellTh rough 
Shipments 



65 



Receipts 

IXlInventoryStalus 



Long POS Header Identifier 
Datc^rime Timer period number 
(beginning of the time 
period) 

Sale to end uset 
Shipments from the 
cmlomcr DC to the 
stores 

ShipmcntJi from the 
vendor (e.g. pcec) to 
the customer dc 
Onhand inventory at the 
ship to location 
(customer dc) 



Double 
Double 



Double 



Double 
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Appendix A 

Database SpeciAcatioiu for Manufacturing Supply 
Chain 

The following are the specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



StorefnventoryStatus Double Aggregate onhnnd 

inventory of stores 
served by the customer 
ship to location 
dc) 

StorcsOnOrdcrQty Double On order quantity from 

the stores to the 
customer dc 

POS Header 

Header file defining the Customer X Product X Tune resolutions i 
values for vaiiOBS POS Data 



POSHcaderfD 
CustomerRcsolution 

OistomerfD 

ProductRcsoliUion 

ProductID 
TimeResolutton 

CnlcndarlD 
DateCrcated 
ScenarioData 
ScenarioCountct 



Product 

Data for end products 

ProductID 

PtoductName 

ProductCatcgory 

Feature] 

Fcature2 

Feaiure3 



Fcature4 
Features 
Features 

ProductDcscription 
SKUSizc 



Long Identifier for the Point 

of Sales Header 

Ttxt Customer Resolution: S 

for Customer Shtpto, C 
for Customer, G for 
Customer Group, A for all 

Text Should be a valid 

customer group or a null 
set (e.g., Selling floor) 

Ttxi Product Resolution: P for 

Product, G for Product 
Group, A for all 

Text Product aesociated with 

the POS Data 

Text D for day, W for week F 

for bi-wcckly; M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 

Long Pegged to a specific 
calendar 

Dote^imc Date the POS Header was 

created or modified 
Boolean Yes if it is sceriario 

data; No otherwise 
Byte Number of scenarios in 

which this header 

participates 



Text SKU from corporate item 

master (e.g. RR1330W) 
Tfext Name of the Product 

Text Product Category 

Text Example: Brand 

Text Example: Screen size 

Text Example: Audio: M-Mono, 

S-Stereo, P-FVologic, D- 

Dolby Prologic 
Tbxt Example: Subtype 

Tfexi Example: Cabinet type 

Text Example: Chassis type 

Ttxt Description of the 

product 

Double Number of product units 

in a SKU (e.g.l) 
Text Height X Depth X Width 

Double Weight of the SKU 



PbysicalDimensions 
Weight 
Product Features 
The feature list of the products 



ProductDitegory Text Product Category 

FcatureNumbet f^ng Feature E^eld Number 

FeaturcNamc Text [■caturc Name Description 



40 



Appendix A 

Database Spedfiaitions for Mooufacturiog Supply 
Chain 

The following arc the specifications of the data tables for 
the manufacluring supply chain. 



Field Identifier 



Field Type Description 



10 Product Group 

Data for product groups 

ProductGroupID 

ProductGroupNa me 



ProdudGroupTag 



Icxt 



Text 



See naiioG roup 



Boolean 



Edentifier for the 
product group 
Descriptive name of 
product group (e.g. 
19Stctco) 

Or^aizational entity who 
defmed the build 
criteria for the product 
group (e.g. Marketing) 
Yes if this is scenario 
group; No otherwise 



Produa Group Dcfmition 
Table that identifies the pa rent -child relationship between 
product groups and producta 



ProductGroupParentlD Text 



ProductGroupChildID 



Identifier for the 
product group that is 
the parent 
Identifier for the 
product group or 
product that is the 
child 

30 Production Accommodation Matrix 

T^blc that identifies alternative production resources for 
producing various products 



PtoductID 



35 Primary Resource ID 



Al te rna ti ve Res ou rce 
ED 



Text Identifier for the 

Product 
Text Edentifier for the 

Primary Production 
Resource 
Text Identifier for the 

Alternative Production 
Resource 
Double Number of units of 
Alternative Resource 
that can substitute for 
I^imary Resource to 
Product 

Frodtiaion Capacity Data 

Production Capacity Data of the production resource identified 
in the header 



Quantity 



ProductionCapacity 
HcaderlD 

TlmePeriod 
50 NoShifts 

LoadingFactor 

YteldFactor 
DowntimeFactor 
55 CapacityRequired 
Ca pactt y AvB i labl c 
Production Capacity 
Header file defining 
resolutions & values 



Long Production Capacity 

Header ID (Sec Production 
Capacity Header Thbic) 
Date/Time Timer period numbter 
Double Number of planned shifts 

during the time period 
Double Planned loading rate 

(e.g. % utilization) 
Double Tirgei yield values 
Double Projected downtime 
Double Capacity required 
Double Capacity available 



Header 

the Production Resource & Time 
for various Production Capacity Data 



PioductCapacity 
^' HcadciID 

ResoutccResoluiion 



Long Production Capacity 
Header ID 

Text N for Production Node, RG 

for Production Group and 
R for Production Resource 

Text Resource (Resource, Group 

or Node) associated with 
an aggregate production 
plan 
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Appendix A 

Database Spccificntions for Manufacturing Supply 
Chain 

The following are the specificatioas of the data tables for 
the mnnufacturing supply chain. 



Field Identifier 



Field 'rypc Description 



CapBcityUnit Text Example, oiimbef of 

production hours, shifts, 
etc. (related to the time 
resolution) 

TmieResolution Text D for day, W foi week; F 

foi bi-weekly; M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 

CalendarlD Integer Pegged to a piedefioed 

calendar 

Date Created Date/Time Datt; when the aggregate 

production plan was 
created (based on the 
time resolution) 

ScenaKoData Boolean Yes if it is scenario 

data. No otherwise 

SccnarioCounter Byte Ntjmbcr of scenarios in 

which this header 
participate! 

Production Matrix 

Aggregate matrix defining the production mtes for Product X 
Resource combinations 



PtoductMatrixID Tbxt 

ResouioeRcsolution Tbxl 

RcsourcclD Ttxt 

ProductBesolution Tfext 

ProduclID Text 

YieldRote Ckiublc 

Time Resolution Tfext 



PraocssTimc Double 
SetupMatrixID Text 

Production Node 

Data for the production node 



ProductionNodcID 



ProductionNodcName 



Text 



Text 



Identifier for the 
production matrix 
Resource resolution 
identifiei 

Unique identifier for the 
production resource 
Ce.g., FAIG) 
Product resolution: C for 
Component, P for Product, 
G for Pnxiuct Group. 
Unique identifier for 
input product (group) 
Actual yield rate for the 
product on the resource 
D for day; W for week; F 
for bi-weekly: M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 
Actual time of production 
Identifier for the setup 
time matrix 



Unique identifier for the 

production node (e.g., 

FTVNodel) 

Name of the production 

node 



Comment Tfext 
Production Requirements Data 

Production Requirements Data far the product identified id the 
header 



PiodReqtleaderlD 



TimePeriixJ 
Quantity 

PiopascdChange 



Ijong Production Requirement 
Header identifier (sec 
Production Requirements 
Data Header tabic) 

Date/Time Time period number 

Double Number of units of 
production 

Double Proposed change with 
respect to the quantity 



20 
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Appendix A 

Database Specifications for Manufacturing Supply 
Chain 

The following are the specificatiDns of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



10 Production Requirements Header 

Header file defining the Product XTimc resolutions & values 
for various Product Requirements data 



ProdReqHcaderlD 
15 APPID 

P roductRcso t uti on 
ProductID 



Time Resolution 



CalendarlD 
DateCieated 



Scenario Date 



30 



SccnarioCounter 



Long E*roduction Requirement 
tleader Identifier 

Text Identifier for an 

aggregate production plan 

Text Product Resolution: P- 

Prodct, G-Group 

Text Product associated with 

the production 
requirements plan 

Text D for day; W for week; F 

for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 

Integer Pegged to a predefined 
calendar 

Date/l^me Date when the production 
requirements plan was 
created (based on the 
time resolution 

Boolean Yes if it is scenario 
data, No otherwise 

Byte Number of sccnzirios in 

which this header 
participates 



Promotional Data 
D^ta related to past and future prormotions for Products & 
35 Customers in the header 



P romo tion Headerl D 



Promotion Header 
Identifier 
Date/Time Timer period number 
(beginning of the time 
period) 

Double Time duration for the 
promotion 
Estimate before the 
promotion for the sales 
qty due to the promotion 
Estimate after the 
promotion for the sales 
qty due to the promotion 

Promotion Header 

tleader file defining the Product X Customer X Time resolutions ift 
values for various Promotion data 



Time Period 



P romo t ion Duratio n 



Ptc-evaluationQty 



Post-evaluatiooQty 



Long 



Text 



Text 



50 PromotionlleaderlD 
CustomerResotulion 

55 CustomerlD 

ProdudResolution 



Product! D 



Time Resolution 



65 CalendarlD 



L^orig tdeatifier for the 

Promotion Header 

Tfext Customer Resolution: S 

for Customer Shiplo, C 
for Customer. G for 
Customer Group, A for all 

Long Should be a valid 

customer group or a null 
set (e.g, Selling floor) 

Text Product Resolution: P for 

IVoduct, G for Product 
Group, A for all 

Text Product associated with 

the promotion Data 

Text D for day; W for week; F 

for bi-weekly; M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 

I'cxt Pegged to a specific 

calendar 
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Appendix A 

D&tabese Specifications for ManufftcturiDg Supply 
Chain 

The following arc the spccificattODs of the data tables for 
the nianufacturtne supply chain. 



Field Identifier 



Field Type Description 



Promotioniypc 
PromotionClass 
Promotionlntcnsity 



P (o mo t ionShape ID 
DateCrcaled 



Text 
Double 



Long 
Date/Tune 



Scenario Data Boolean 
ScenarioCountei Byte 
Resource 

Data related to production resource 



ResourcelD 



ResourceName 
RcsourccGroupID 



Tfext 



Text 



MaxLineliate Double 
NoWorkstations Double 
MaxBuffers Double 
Resource Group 

Data related to production resource group 



R for RetaUer; P for 
PCEC; C for Competitor 
Promotion class (e.g. 
Price Reductions) 
Intensity of the 
promotion (iovj, medium, 
high) 

Date of creation of the 
Promotion Header 



Unique identifier for a 
production resource 
(e.g.. FAIG) 
Descriptive name 
Production group this 
rcsouroe belongs to 
Maximum line rate 
Number of wcrkBlationa 
Maximum number of buEfcis 



ResoutceGroip ID 


Tfext 


Unique identifier for the 






production group (e.g.. 






Plant4) 


ResoutoeOroupName 


Text 


Descriptive name 


ProductionNodelD 


T^xt 


Production node this 






group belongs to 


Attribute 1 


Text 


Attribute (e.g., 






Category, Location) 


Attribute2 


Text 


Attribute (e.g.. 






Category, Location) 


AttributeJ 


Text 


Attribute (e.g.. 






Category, Location) 


Scenario Group 


Boolean 


Yes if this is scenario 






group; No otherwise 



Resource Group Definition 

Tkble that defines the parent-child relationship of the 
production resource group and production resouroeg 



ResouroeOroupParentlD Tfext 



ResourccGroupChildlD Tfext 



Identifier for the 
resource group that is 
the parent 
Identifier for the 
resource group or 
product that is the 
child 

Sales Requirements Data 

Sales Requirements data for the product identified in the 
header 



SalesRcgHeadciID 



TimePcriod 



Ixing HcaderlD pegged to the 

Sales Requirement Header 
tabic 

Date/Time Time Period pegged ID the 
time resolution in the 
Sales requirements header 
table 

Quantity Double Quantity required 

Sales Requirements Header 

Header file defining the Product X lime resolutions & values 
for the sales requirements data 



SalcsRcqHeaderlD 



l-ong 



E leader ID of the sate: 
requirements 



J5 
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-continued 

Appendix A 

Database Specifications for Manufacturing Supply 
Chain 

The following arc ttie specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Field Type Description 



10 PtoductRcBolution 



ProductID 
Time Resolution 



CalcndarlD 
DateCicalcd 



Scenario Data 
ScenarioCounter 



Text 



Text 
Text 



Long 
Date/Time 



Byte 



Scenario 

Sccncrto description and user information 



Production Resolution: 
P - Product, PG - Product 
Group, A - All 
Product ID 

Time Resolution: D-Day, 
W- Weekly, M- Monthly. Q- 
Quarterly, Y- Yearly 
Calendar ID 
Date of creation of the 
sates requirements 
Yes if it is scenario 
data, No otherwise 
Number of scenarios in 
which this header 
participates 



Scenario ID 
25 Scenario Name 
User 

Description 
DateCreated 
DateUpdated 



Long 

Ttxt 

Ttxt 

Memo 

Dale/Time 

Date/Time 



Scenario Data Compatibility 
30 Table that specifies what data headers can be loaded into each 
of the data pockets on each fotm for each frame 



Frame 
Form 
Pocket 
TableName 



Text 
Integer 
Integer 
Text 



Frame Name 
Form Number 
Pocket Number 
Tabic name for the 
(Frame, Form, Pocket) 
triple 



Scenario Definition 
The table that contains the header ids of the various data 
that exists in each pocket, in each form in each frame for 
difTerenl scenarios 

ScenarioID Long 

Frame Ttxt 

Fotm Integer 

Pocket Integer 

HeaderlD Long 

DatcCicated Datc/Tlme 

Date Updated Date/Time 
Setup Matrix 

Aggregate matrix defining the sequence-dependent setup times 
for product changecrvcrs 



SctupMatrbdD 



PrevProductlD 



55 NexiProdualD 



Hme Resolution 



60 



Tfext Identifier for the Setup 

Matrix 

Text Identifier of the product 

that has just finished 

processing 
Tfext Identifier of the product 

to be set-up on the 

resouruc 

Text D for day; W for week; F 

for bi-weekly: M for 
monthly; B for bi- 
monthly; Q for quarterly; 
and A for annually. 
Double Actual time to set up 



Sctupllmc 
Supply Chain Network 

Structuml data specifying the supply chain network 



65 Link ID 



Text 



Supply chain network link 
identifiei 
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Appendix A 

Database Specificalions for Manufacturing Supply 
Chain 

The following are ihc specifications of the data tables for 
the manufacturins supply chain. 



Field Identifier 



Field type Description 



FramNodelD 



ToNoddD 



Linkctipacity 
TransporLLea dTun e 

Distance 
Linklndicetor 



Tfcxt 



Text 



Double 
Double 



Double 
Boolean 



A node ID from any of the 
three node classes: 
compODcnt supply, 
production inventory 
A node ID from any of the 
three node classes: 
production, inventory, 
demand 

Capacity of the link 
Transport Lead time 
associated with the link 
Transportation distance 
Yes if it is currently 
active and in use and No 
otherwise 



Supply Order Data 

Data for the supply orders identified in the header 

SupplyOrdcrtlcaderlD Long Production or supply 

order (e.g. pccc type 4 
orders) 

OrderDatc DateAnme Date of creation 

expressed with respect 
to calendar 
Text Orientation order 

associated with supply 
order 

Dote/rime Date the supply order is 
due 

Double Quantity of the simply 
order 
Supply Order Header 

Header file defining the Product X Custonier X nme resolutions & 
values for supply orders 



OrientationDatalD 

Due Date 
Quantity 



SupplyOrderHeaderlD 
Custom c rReso 1 utio a 

Custonier[D 
Product Evolution 

ProductlD 
TimeRcsolution 



CalendarlD 
DatcCrcated 



Scenario Data 
Sec narioCDuntc r 



Long 



Production or supply 
order (e.g. pccc lypc 4 
ordeis) 

S for customer ship to; 
C for oistomen 0 for 
ciutamcr group; M for 
market; A for atl 
customers 

Customer identified with 
the place keeping order 
P for product; G for 
product group; A for all 
products 

Product associated with 
the supply order 
D for day; W for week; F 
for bi-weekly; M for 
monthly; B for bi- 
monthly; 0 for 
quarterly; and A for 
annually. 

Pegged [Q a calendar 
Date/Tune Date the Supply Order 
Header was 
created/modified 
Boolean Yes if it is scenario 
data, No otherwise 
Number of scenarios in 
which this header 
participates 



Text 



Text 



Text 



Text 



Text 



Long 



B>tc 



Appendix A 

Database Specifications for Manufacturing Sqjply 
Chain 

The following arc the specifications of the data tables for 
the manufacturing supply chain. 



Field Identifier 



Re Id T^pe Description 



Temporary Product List 

System table that contains a temporary product list 

ProdualD Text 
VMR Cdntiact 

^ j Data associated wkh a Vendor Managed Replenishment Contract 



VMRContractID 

Contract Date 
ExpiratioaDate 

PaynientTerms 
ProductResolution 



25 



TargctFillRate 

TurnAroundTime 
Minlnventory Factor 



30 



MaxI n ve n tory Fact 0 r 



Ordei Re V is io nFacto r 

^5 VMR Data 

Data associated with 
customers identified 



IdenUfier for the VMR 
Contract 

Date of the contract 
Bxpiretion date of the 
contiact 

Example: Net-60, Net-30 
E*roduct Resolution: P 
for Product, G for 
Product Group, A for all 
Product associated with 
the VMR contract 
Fill rate promised in 
the VMR contract 
Nominal turnaround time 
Minimum inventory factor 
agreed in the VMR 
contract 

Maximum inventory factor 
agreed in the VMR 
contract 

Customer's rights to 
revise order 



Vendor Managed Replenishment for the 
in the header 



Text 

Date/Tune 
Date/Tune 

Text 
Ttxt 



Text 
Double 



Double 
Double 



40 



50 



60 



VMRHeaderlD 
OrderDatc 

PurchascOrderlD 

OrdctStatus 

OrdcrQty 

CumDcliveryQty 

DueDate 

De live red Date 

ShipDatc 
I^stShipmentDate 

ShipCarrier 

LinkiD 



65 FteightRatcTablelD 



Long VMR Header Identifiet 
Date/Time Date when the VMR order 

data was entered 
Text Customer purchase order 

reference 
Text A for allocated; B for 

backordered; 
Double Quantity associated with 

the order 
Double Quantity delivered 

against the order 

(cumulative measure) 
Date/Time Date when the order is 

planned to be delivered 

at the customer site 
Date/Hme Date when the order was 

actually received at the 

customer site 
Date/Time Date when the order is 

planned to be shipped 
Datc/Ttmc Date of the latest 

shipment - made to 

fulfill an order 
Date/Time llie carrier used in 

delivering the order (to 

keep track of the 

intra n sit inventory) 
Ttxt Pegged to a defined 

supply chain link in the 

EUf^ly chain network 

tabic 

Text Based on iranspo nation 

mode 
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Appendix A 


Database SpeciAcations for Manufactufing Supply 




Chain 


The roDowiDg arc 


the specifications of the data tables for 


the manufacturing supply chain. 


Field Identifier 


Field Type Description 


VNIR Header 




Header file defining the Product X Customer X Time resolutions & 


vales tor vivik 




VMntlCadCnU 


Ljung viviiv ii^duci luciiuiici 


Oustome rResol ut io n 


lexi v-usiorrer Kesoiuiion. & 




for Customer Shipto^ C 




for Customers 0 for 




Customer Group, A for all 


CustomerlD 


Tbxt Should be a valid 




customer group or a null 




set (e.g.. Selling floor) 


Product Resolution 


Tfcxt Product Resolution: P for 




tnfouuct, kj lor rrouuci 




Group, A for all 


ProductID 


Text Product covered by the 




VMR contract 


TimcRcsofution 


Thxl D Cor day; W for week; F 




for bi-weekly; M for 




monthly; B for bi- 




monthly; Q for quarterly; 




and A for annually. 


CalendarlD 


Integer Pegged to n predefined 




calendar 


1 a vento ryCon t ro) I D 


T6xt Pegged to inveniory 




control parameters ID 


VMRContractID 


Text Pegged to the VMR 




Contract table 


DateCreatcd 


Date/nme Date the VMR Header was 




created/modified 


SccttarioData 


Boolean Yes if it is scenario 




data. No otherwise 


ScenaiioCounter 


Byte Number of scenarios in 




which this header 




participates 


APPENDIX B 


Database Specifications for Equipment Repair Supply 




Chain 


The following are 


the specifications of the data tables for 


ttie equipment repair supply chain. 


Etjuipment 




Information lo classify equipment into groups. This 


information is relevant to identify reliability 


characteristics of equipment parts. 


Field Identifier 


Field Description 


EquipmcntlD 


Unique idcntitier for the equipment 


fLqutpmcntljocation 


Location of the equipment 


Inspeciionl^ocation 


I^ocation where the equipment is 




inspected/maintained 


DateofMfg 


Year of manufacture of equipment 


RunmngI lours 


Tbtal Cumulative running hours so far 


Region 


Region of reconnaissance associated 


with the equipment 


Characterislic 


Other critical characteristic, e.g., 


(Identify) 


total running time 


etc. 





APPENDIX B-coDtinued 



Database Specifications for Equipment Repair Supply 
Chain 

The following are the specifications of the data tables for 
the equipment repair supply chain. 





Repairable Item and Comp< 


onent Information 




(Zomponenl 




10 


Field Identifier 


Reld I>escription 




ComponenifD 


Component ID in the BOM 




CbmponcntNamc 


Name of the component 




MinPact Quantity 


Minimum pack quantity 




P h ys ical Pb ram eter 


Physical dimensions for the component 


15 


CompCaiegory 


S for Off-the-shelf; C for Customized 




Packagi ngl ns tructio n 


Special packaging requirements 




BOM 






Engineering Bill of Material that describes the product 


20 


structure from equipment to repair items to components 




Field Identifier 


Field Description 




BOMID 


Unique identifier for the engineering BOM 




ParcnlTVpc 


Type of the porcnt: Equipment/Repair 






ttemyCbmponent 


25 


ParenllD 


Idcntiftci of the parent (EquipmentID or 






RepairltemID or ComponenilD) 




Childiype 


Type of the child (Repair Item/Component) 




ChildID 


Unique identifier for the child 






(RepairltemID or ComponenilD) 


30 


Quantity 


Number of components used in parent 




Repairable Item 






Characteristics of repairable item 




Field Identifier 


Field Description 


35 


RepairltemID 


Unique idenlifieT of the repair item 




RcpairltcmNamc 


Name/Description of the repair item 




Ph ysical Dime nsions 


Height XDepth XWidlh 




Weight 


Weight of the SKU 


40 


Component Supplier 






Information related to component BuppHcr 




Field Identifier 


Field Desciiptton 




CompSupplicrlD 


Unique identifier for the coinpoDcnt 


45 




supplier 


SupplierName 


Name of the component supplier 




PaymcntTerms 


Example: Net-60 




StreelAddrcss 


Street Address 




StatelD 


Name of the SUte 




PostolCodc 


Postal code 


50 


Country 


Name of the country 




Supply Information 






Repair Time Matrix 






Aggregate matrix defining the repair rates for Repair Item X 


55 


Repair Resource combinations 




Field Identifier 


Field Description 




Repair Matrix ID 


Identifier for the repair matrix 




Res ou rcc R csol u t io n 


Resource resolution identifier 




ResourccID 


Unique identifier for the repair 


60 




resource 




RepairltemID 


Unique identifier for the repair item 




Time Resolution 


D for day; W for week F for bi-wcckly; 






M for monthly; B for bi-monthly; 0 for 






quarterly- and A for annually. 




Ptocas'nme 


Mean time lo rqpaii 


65 


ScUipMotrixID 


Identifier for the setup time matrix 
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APPENDIX B-continued 



Database SpecificatLons for E^ipment Repair Supply 
Chain 

The followuig are tbe specifications of the data tables for 
the equipment repair supply chain. 

Repair Setiy Matrix 



Aggregate matrix defining the sequence dependent setup times 

for repair item changeovers 

Field Identifier Field Description 



SetupMalrixlD 


Identifier for the Setup Matrix 


PtcvPtoduclID 


Identifier of the repair item that has 




must been repaired 


NcxtProductID 


Identifier of the repair item that needs 




to be repaired 


TimeRe solution 


D for day, W for week; F for hi-weetly. M 




for monthly; B for bi-monthly; Q for 




quarterly; and A for annually. 


SetupTune 


Actual time to setup 



Repair Capacity Header 



Header file defining the Repair Resource X Time resolutiorK & 
values for various Repair Capacity Data 
Field Idetitifier Field Ctescription 



RepairCapacttylleader 


Repair (^opacity Header ID 


ResoutceResolution 


Resource Group or Resource 


ResoutoelD 


Resource ID 


CapacityUnit 


Example, number of production hours. 




shifts, etc. (related to tbe tiinc 




resolution) 


TimeResolutioD 


D for day; W for week; F for bi- 




weekly; M for monthly; B for bi- 




monthly; Q for quarterly; and A for 




annually. 


CalcndarlD 


Pegged to a predefined calendar 


DateCreated 


Date when the aggregate repair plan 




was created (based on the time 




resolution) 


Repair Capacity Data 




Repair Capacity Data of the repair resource identified in the 


header 




Field Identifier 


Field Description 


RepairCapacLtyDatal D 


Repair Capacity Data ID 


Time Period 


lime period number 


RepairCapacityi leaderlD 


Repair Oipacity Header ID (Sec Repair 




Capacity Header Tbble) 


NoShifts 


Number of pbnncd shifts during the 




time period 


LoadingFaclor 


Planned loading rale (e.g. % 




utilization) 


Down time Factor 


Projected downtime 


CapacityRequired 


Capacity required 


Cap BC it y Avai lab Ic 


Capacity available 


Repair Bstimatton Header 




Header file defining ibe Item X Tunc resolutions & values for 


various Repair Estimation data 


Field Identifier 


Field Description 


RepairBstHcaderlD 


Repair Bstimatton Header Identifier 


ARPID 


Identifier for an aggregate repair plan 


llemID 


Item associated with the production 




requirements plan 


Time Resolution 


D for day; W for week; ¥ for bi-weekly; 




M for monthly: B for bi-monthly; 0 for 




quarterly; and A for annually 


CalcndarlD 


Pegged to a predefined calendar 


DateCreated 


Date when the Repair Estimation plan was 




created (based on the time resolution) 
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APPENDIX B-coDtinued 



Database Specifications for Equipment Repair Supply 
Chain 

The following are the spedftcatioas of the data ubies for 
the equipment repair supply chain. 

Repair Estimation Data 

Repair Estimation Data for the repair item identified in the 



20 



header 




Field Identifier 


Field Description 


RepairEstDatalD 


Repair Estimation Data ID 


TimePcriod 


Time period number 


RepairEstHeaderlD 


Repair Estimation Header Identifier 


Quantity 


Number of units of production 


ProposcdChangc 


Proposed change with respect to the 




quantity 


Aggregate Repair Plan Header 


header file defining the Repair Item X Resource X Time 


rcwlutiona & values for 


various Aggregate Repair Plans 


Field Identifier 


Field Inscription 


RcpairPlanHcaderlD 


Repair Plan E>ata Scries Identifier 


RepairlD 


Identifier for an aggregate repair 




plan 


Rcsou tocRcsolulion 


Resource Resolution: R-Rcsourcc, 0- 




Oroup, N-Node 


ResourtselD 


Resource associated with the repair 




plan 


Repair ItemResolution 


Repair Item Resolution: P-Repair 




Item, G-Group 


RepairltemlD 


Repair Item associated with the 




repair plan 


TimeResolution 


D for day; W for week; F for bi- 




weekly; M for monthly; B for bi- 




monthly; Q for quarterly; and A for 




annually. 


CalcndarlD 


Pegged to a predefined calendar 


DateCreated 


Date when the aggregate prodoction 




plan was created (based on the time 




resolution) 



Aggregate Repair Plan Data 



Data related to the aggregate repair plan for the repair item 
identified in the APP header 



55 



Field Identifier 


Field Description 


RepairPlanDatalD 


Identifier for the Repair Plan Data 


TimePcriod 


Time period number 


Repair PlanHcadcrlD 


Repair Plan Head identifier (see 




aggregate repair plan Header table) 


Quantity 


Number of units to be repaired 


ProposcdChangc 


Recommended change in the planned 




quantity (to store changes between 




regeneration of Repair Plans) 


Component Estimation Header 


Header file defining the Cooiponenl X 'lime values for various 


component requirement data 




Field Identifier 


Field Description 


CompEstHeaderlD 


Component Estimation Header Identifier 


ComponentID 


Component associated with an t»mponcnt 




estimation header 


BOMID 


Unique identifier for BO}A 


DateCreated 


Date when the component estimation was 




created (based on the time resolution) 


Time Resolution 


D for day; W for week; F for bi-weekly; M 




for monthly: B for bi-monthly; Q for 




quarterly; and A for annually. 


CalcndarlD 


Pegged to a predefined calendar 


RepairPlanlD 


Pegged to an aggregate repair plan (if 




warranted) 
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APPENDIX B-coQtinued 



Database Specifications for Equipment Repair Supply 
Chain 

The following are ibe specifications of the data tables for 
Ibe equipment repair supply chain. 

Component Estimation Data 

Data related to requiremenis for the component identified in 
the header 



Field Identifier 


Field Description 


CompEstCtetalD 


Coinponent Estiniation Header ID (Sec 




Component Estimation Header Tabic) 


Tiine Period 


Time periixl number 


ComRcqHeaderlD 


Identifier fof the oomponenl estimation 




headei 


Quantity 


Number of units during the time period 


ProposedChange 


Proposed Change in required quantity 



Material Delivery Schedule Header 

Header file defining the Component XSupplier XTImc 
resolutions & values for various material delivery.schedulcs 



20 



Field Identifier 


Field Description 


MDSHeadexID 


Identifier for the Material Delivery 




Schedule Header 


Compo ne ntSupply Nodel D 


Identifier for component supply node 


SupplicrlD 


Supplier associated with a Material 




Delivery Schedule 


TimeResolution 


D for day; W for week; F for bi- 




weekly; M for monthly; B for bi- 




monthly; Q for quarterly; and A for 




annually. 


CalendarlD 


Pegged to a predefined calendar 


DateCreated 


Date when a Material Delivery Schedule 




was created (based on consistent time 




uoits) 


Material Delivery Schedule Data 


Material Delivery Schedule for the Component identified in the 


header 




Field Identifier 


Field Description 


MDSDatalD 


Identifier for Material Delivery Schedule 




Data 


Delivery Date 


Material Delivery Date 


MDSHeadcrlD 


Identifier for the Material Delivery 




Schedule Header 


Quantity 


Number of units of material delivery 



Requirements Information 
Requirements History Header 

Header file defining Equipment XRcpair Item X Time 
resolutions & values for various demand histories 



45 



Field Identifier 


Field Description 


ReqHistltcaderlD 


Identifier for a requirements history 




header 


RepairttcmResolutton 


? for repair item; G for repair item 




Group; A for all repair items 


RepatrltemID 


Repair Item associated with 




requirements history 


Fqu ip mc n t Rcso lu t ion 


C For Equipment; CG for equipment 




group: A for all equipment 


Equip menllD 


t^uipmcnt (Group) associated with 




rcqutrcittcnts history 


TimeResolution 


D for day; W for week; F for bi- 




weekly; M for monthly; B for bi- 




monthly; 0 for quarterly; and A for 




annually. 


CalendarlD 


Pegged to a predefined calendar 



Requirement History Data 

Data for the demand history for the product defined in ihe 
header 



Database Specifications for Equipment Repair Supply 
Chain 

The following are the specifications of the data tables for 
the equipment repair supply chain. 



Field Identifier 


Field Description 


ReqHistDatalD 


Requirements History Data identifier (see 


10 


Requirements History Header tabic) 


Time Period 


Time period number 


RcqHisiHeaderlD 


Identifier for a requirements history 




header 


RcquircmcntsQty 


Requirements Quantity 


1 Equipment Repair Orders 




Data for actual equipment repair orders 


Field Identifier 


Field Description 



RepairOrderrD 

LineltemID 

RepairOricrRcfNo 

EquipmenilD 

RepairltcmID 

CalendarlD 

HmeResoIution 



25 

OrdeiEntryDate 
RequestedlDstc 
DueDate 

30 

ShipDate 

Delivery Date 

Quantity 
35 Comments 



ID for the actual equipment repair order 

Line item within the order 

Repair order identifier 

Equipment identified with the order 

Repair Item associated with the order 

Pegged to a calendar 

D for day; W for week; F for bi-wcckly; M 
for monthly; B for bi-monthly; Q for 
quarterly; and A for annually. 
Expressed in terms of the calendar and 
time resolution 

Expressed in terms of the calendar and 
lime resolution 

Expressed in terms of the calendar and 
time resolution 

Expressed in terms of the calendar and 
lime resolution 

Expressed in terms of the calendar and 

time resolution 

Quantity of the order 

Such as value added services associated 

with the order 



Future Requirements Header 

Pleader file defining the Customer XProduct XTune resoluiions 
& values for various future requirements. 
Field Identifier Field Description 



FutureReqHeaderlD 
Repair ItemResolution 

Repair [temID 

EquipmentResotution 

EquipmentID 

TimeResolution 



50 



CalendarlD 
DateCreated 

55 FulReqTypc 

EstimationAssumptions 

EstimalcOwner 



Riture Requirements Header Identifier 
P for Repair Item, G for Repair Item 
Group, A for all Repaired Ilcms 
Repair Item (Group) associated with 
forecast 

C for Equipment, CG for equipment 
group; A for all equipment 
Equipment (Group) associated with 
requirements history 
D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; O for quarterly; and A for 
annually 

Pegged to a predefined calendar 
Date when the forecast was created 
(based on tfie time resolution) 
B for bottom-up; T for top-down 
Assumptions associated with the 
estimation 

Author of the future requirements 



60 



Future Requirements Data 

Data associated with the Eiiture requirements for the 
equipment-repair ilcms identified in the header 
Field Identifier Field Description 



FutureReqDatalD 



Time Period 



Future requirements data series 
idcntifici 

Time period number 
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APPENDIX B-continued 



Database Specificatioits for Equipment Repair Supply 
Chain 

The following are the speciftcaLioos of the data tables for 
the equipment repair supply chain. 

FutureReqllcaderCD Pegged to the Future RequiTcmcnts Header 

Estimate Value Ftiture requirements data vaJue 

EstimateCV CoefGcicnt of variation of estimate 

Activity Header 

Header file defining Ibc Equipment Group XRepair Item XTImc 
resolutions & values for various Activity data 
Field Identifier Field Description 



ActivityHeaderlD 
EquipmeatRcsolution 



EquipmeatID 
RcpairftccnResotution 

Rq^airltcmlD 
■nmeRcsolulion 



CatendailD 
Aclivityl^pc 
ActivityClass 
Activitylntensity 

ActivityShapelD 



Identifier for the Activity Header 
Equipment Group Resolution: C for 
Equipment, G for Equipment Group, A 
for all 

[D of the equipment associated with 
the activity 

Repair Item Resolution: P for Repair 
Item, G for Repair Item Group, A for 
all 

Repair Item associated with the 
activity Data 

D Cor day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 

Pegged to a specific calendar 
Company wide, location level, etc. 
Activity class 

Intensity of the activity (low, 
medium, high) 
Intensity of the activity (low, 
medium, high) 



Database Specifications for Equipment Repair Supply 
Chain 

The following are the specificatiotis of the data tables for 
the equipment repair supply chain. 



Inventory Data 

Inventory data for items identified in the header 
10 Field Identifier Field Description 



20 



Activity Data 




Data related to past and future activities for the equipment 


Field Identifier 


Field Description 


AclivityDatalD 


Activity Data Series Identifier 


TimePeriod 


Timer period number (beginning of the 




time period) 


ActivityHeaderlD 


Activity Header Identifier 


ActivityDuraiion 


Time duration for the activity 


Pre- 


Estimate before the activity for the 


cvaluationQty 


quantity due to the activity 


Posl- 


Estimate after the activity for the 


evalualionQty 


qiiantity due lo the aaivity 


Inventory Information 




Inventory Header 




Header file defining the Repair Item X 'time resolutions & 


values for various inventory data 


Field [dcDtifier 


Field Description 


InvenioryHeadcrlD 


Inventory Data Series Identifier 


InvenloryNodelD 


Identifier for an inventory logic 




warehouse 


1 nvento ryControl I D 


Identifier for inventory control 




parameters 


IlcmResolution 


Item Resolution: C for Component, P for 




Product, G for Product Group and A foi 




All 


RcpairltcmID 


Repair Item ID 


Time Resolution 


D for day; W for week; F for hi- weekly; 




M for monthly: B for bi- monthly; 9 for 




quarterly; acd A for annually. 


CalcndarlD 


Pegged to a predefined calendar 


Minlnventor)' Level 


Minimum inventory level for the item 


Maxlnventory Level 


Maximum inventory lc\-el for the item 
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InvcntotyDatalD 


Inventory data identifier (see 




Inventory Header table) 


TimePeriod 


Time period number 


InvcntoryHeaderlD 


Inventory Data Series Identifier 


On Hand Inventory 


On-hand available inventory for 




allocation 


OnOrdcrlnventory 


On- order inventory 


Baclco rd cr I n vcntory 


Back-ordered inventory 


InTransit 


In-transit quantity 


Rese rvedl n ve n lory 


Reserved inventory on-hand but 




available for allocation only in case 




of emergency 


Invetuory Parameters 




Data for the inventory control paramctccs 


Field Identifier 


Field Description 


Inve nto r yCo n tro 1 1 D 


Identifier for inventory control 




parameters: Assume inventory 




planning • inventory control 


Sa fctySt ockFact or 


Safety stock factor 


TargptScrvicc Level 


Tkrgcl service level 


PolicyType 


Policy type: SS, M in/Max, QR, etc. 


M inlnvcntDryFactor 


Minimum inventory factor (e.g., in 




terms of weeks of sales) 


MaxI n ve niory Faaor 


Maximum inventory factor (e.g., in 




terms of weeks of sales) 


MinOrdetQty Factor 


Minimum order quantity factor 


CarryCha rgcFactor 


Carrying cost factor 


OrdciCha rgc Factor 


Ordering cost factor 


InventoryClass 


Inventory classification 


RepIcnishmenlFrequency 


Frequency of replcnbhmcnt w r.t the 




time resolution in the header 


Repair Resource Information 


Information related to the repair technician and test 


equipment 




Repair Resource 




Data related to repair resource 


Field Identifier 


Field Description 


RcpairResID 


Unique identifier for a repair lesource 




(e.g., FAIG) 


Repair RcsNamc 


Descriptive name 


Repa irRcsGroupID 


Repair resource group this resource 




belongs to 


Maxl.ineRate 


Maximum line rate 


NoWorkStations 


Number of workstations 


Repair Resource Group 




Data rclalcd to production resource group 


Field Identifier 


Field Description 


RepairResGroupID 


Unique tdentifier for the repair 




resource group (e.g., Planl4) 


RcpairRcsGroupName 


Descriptive name 


Repair Mode ED 


Repair node this group belong; to 


Attribute 1 


Atlribmc (e.g.. Category. IvOcaiion) 


AttributcZ 


Attribute (e.g., Qitcgory. Location) 


Attributc3 


Auributc (e.g., Qitcgory. Location) 
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APPENDIX C 



APPENDIX Ooontinued 



Interim Design Documentation foi the System 
Integrator of the Supply Frame Chain Manager 

Class name: 

FrameManager 

Category: Supply Frame Chain Manfiger 

DcxximcDtation: 

This is a singleton class. It is ninning 
on the server, [t has to be started 
before a client can start and make 
connection to it. The FrameManager is 
responsible to facilitate the integration 
of the client side of the system (the User 
Interface 18) with tlie server side of the 
Eystem where the mathematical Model 
[inginc5 and the DSS 10 database reside. 
The FrameManager is composed of a 
OientManager, a ScrverManager, a 
collection of Requestlnterpreter and 
objects which fonn the Functional 
Integrator 312. When a client program 
start up, it will connect to the 
FrameManager (obtain the object reference 
of the FrameManager) and call the 
initialization function. As port of the 
initialization of the client with the 
FrameManager, a Requestlnterpreter object 
will be created, inserted into the 
collection and the object reference will 
be return back to the client. The client 
will also be registered with the 
aicntMaiHger object of the FrameManager. 
The initialization also includes the user 
authentication. 
Export Control: Public 
Cardinality: 1 
Hieiarcby; 

Superclasses: none 
Associations: 

<no iolename> : ClientManager in 
association 

<no ialename> : Requestlnterpreter 
in association 

<no rolcnamo : ScrverManager in 
association 

Public Interface: 
Operations: 

FrameManager 
initializeClient 

Private Interlace: 
Attributes: 

mOientMnnnger : 

ClientManager 

mServerManager : 

ScrverManager 

m Requestlnterpreter : 

LisKRequestlnte rp rete r> 

A linked list of 
Request! nlcrpreter. Eiach Requestlnterpreter will 
run in a separate thread or a separate process. This 
way, requesU from multiple clients can be handled 
concurrently. 

Slate machine: No 

Qjncurrency; Sequential 

Persistence: Transient 

Operation name: 
FrameManager 

Public member of: FrameManager 
Arguments: 

char" frameMgiConfigFile 

Documentation: 

This is the conslruetoi is the 
FrameManager. At the construction time, it will read 
in the configuration information from o file 
(-framcMgrConfigFitc"). The information include 
things such as the name of the DSS Da In base and on 
which host it is running, where arc the Model 
Kngines (installed on which machines), how many 
nuird>er of simultaneous client are allowed to connect 
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to the FrameManager, etc. The constructor is also 
responsible to initialize all other data member of 
this class. 

Concurrency: Sequential 

Operation name; 

initializeClient 

Public member of: FramcManagei 
Return Class: Reqiiestlnterpieter& 
Arguments: 

char* userNamc 

char* hoslName 

char* password 

NotifyMsg& notifyMsg 
Documentation: 

Once the client program has started and 
obtained the object reference of the FrameManager, 
it will call ihis function to initial itself with 
the FrameManager. It will pass in the user name, 
password, host name, etc. TTie information will be 
used for auihCDiication and registering with the 
ClientManager. The object reference of a NotifyMsg 
on the client side will pass in. Thb object 
reference will be used to tiotify the client about 
its request when it make an asynchronous request. 
(Aayncbronous request will be allowed when the 
client request to lun some of the strategic decision 
model.) 

This function will return the object 
reference of a Requestlnterpreter through which the 
client will make all its requests. 

Concurrency: Sequential 

Class name: 

ClientManagfcr 

Category: Supply Frame Chain Manager 

Documentation: 

Manage and monitor the client conaedion. 
Implement client connection policy, such as "after 
certain period of inactive time disconnect the 
clienf "the total number of client connection can 
not exceed certain number". Also resposibtc to 
delete the corresponding Requestlnterpreter object 
after a client is disconnected (in such case as the 
client machine goes down, or the network connection 
is lost). 

lixport Control: Public 

Cardinality: 1 

Hierarchy: 

Superclasses: none 
Associations: 

<no rolcnamo : FrameManager in 
association 

Public Interface: 
Operations: 

registerCIieat 
maintainClient 

Private Interface: 
Attributes: 

clients : List<Client> 

A linked list of 
Client. The aient class contain the basic 
information about the client, such as, the user 
name, the clici:t host name, the corresponding 
Rcqucstlntcrpictcr, time of initial connection, time 
of last request, pending requests, etc. 

State machine: No 

Concurrency: Sequential 

Persistence: Transient 

Operation name: 

regi&tcrQicnt 

Public member of: ClientManager 
Return Class: bool 
Arguments: 

Client* aClicnt 
Dcxaimcntatlon: 
Add a client to the client list. Enforce 
the relevant FrameManager poIic>' such as the maximum 
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APPENDrX C-continued 



APPENDIX C-oontinued 



Inierim Design DocumcBtation for the System 
Integrator of the Supply Frame Chain Manager 



[nterim I>sign Documeatatton for the System 
[ntcgiBtor of the Supply Fmine Qiain Manager 



number of simultaneous client. 
Concurrency: Sequential 
Operation name: 
maintainClicDt 

Public number of: ClientManagcr 
Documentation: 

This function will be called periodically 
from the FramcManager. Within the function, each 
client will be checked to see if it needs to be 
disconnected If a client needs to be disconnected, 
it will be removed from the list and the 
corresponding Requcstlnteipreter object will be 
detclcd. 

Cbncurrerxry: Sequential 

Cass name: 

Request Interpreter 

Category: Supply Frame Chain Manager 

DocumcDtation: 

Thb Is the object the client is Dormally 
interact with. Each object of this type has to run 
in its own thread or process so that multiple client 
can request server services concurrently. 

Export Control: Public 

Cardinality: □ 

Hierarchy; 

Superclasses: none 
Associations: 

<no rolenamo : FramcManager in 
asscxiatioa 

Public Interface: 
Operations: 

request 

Private Interface: 
Attributes: 
IhcCLient : Client- 
Reference to the dient with 
whom this Interpreter is associated. 
Stale machine: No 
Concurrency: Sequential 
Persistence: Transient 
Operation name: 
request 

Public member of: Requesllnteipreter 

Return Class: bool 

Arguments: 

long scenario ID 

long domainID 

long requcsiID 

booi asynch 

long& fesullID 
Documentation: 

This function will be called by the client 
to make a request to perform certain teak by the 
scivcr(s). The scenariotD and dontainlD will identify 
the data associated with the requesL The requestlD 
will Identify what Idod of action need to be 
performed (by looking tip a tabic within the system). 
If the request is not asynchronous ("asynch" false") 
the result will be returned immediately through the 
value of rcsultlD. The client can retiicvc the 
actual dau from the DSS Database through the 
resuttID in the table associated with thai type of 
request. If the lequest of aynchronous, the 
result will be sent to the client later by calling 
the NotifyMsg object of the client 

Concurrency: Sequential 

aa.s.s name: 

ScrverMaoager 

Category: Supply Frame Chain Manager 

Documentation: 

Manage the server connection. A server is 
a program (an object) from which wc can request 
specific service. Foi enample, we may have a server 
being able to compute the optimal delivery frequency 
given the maximum inventory and scr%icc level 
constrain in a VMR setting. This is referred as 
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Model Engine Servci. A Model Engine Server can run 
on the same machine where the FrameManager Is 
running, or it can run on different machine. Two 
Model Engine Servers of the same type can run on the 
same machine, or they can run on different machines. 
The information governing the policy is stored in 
the FramcManager configuration file which was read 
in at the time of constructing the FrameManager. 
The ServerManager will enforce the policy such as on 
which machine to start which server, load balancing, 
etc. The ServerManager is also responsible to 
shutdown the servers when they are not needed. 

Export Control: Public 

Cardinality.: 1 

Hierarchy; 

Superclasses: none 
Associations: 

<no rolename> : FrameManager in 
association 

Public Interface: 
Operations: 

addScrver 

maintainScrver 

getServer 

Private Inlcr&cc: 
Attributes: 

servers : List<Scrver> 
A linked list of 
Server object. A Server is a dass which record the 
basic information about a server, such as name, 
type, which host it is running on, status, etc. 

State machine: No 

Concurrency: Sequential 

Peisisteace: Transient 

Operation name; 

addServer 

Public member of: ServerManager 
Return Class: bool 
Arguments: 

char* aServer 
Documentation: 

Try to start a new server of certain type 
and add it to the server lisL Here some of the 
server management policy will be enforced. For 
example, we may have a policy says that there should 
be no more than x number of Linear Programming 
servers in the entire system. Or we may have another 
policy says that we can not put more than x number 
of servere (of all types) on machine A. When the 
function is called only the name (type) of the 
server is passed in. Which machine the server should 
be on is detennined within this function. 

Concurtcncy: Sequential 

Operation name: 

maintainServer 

Public member of: ServerManager 
Documentation: 

This function is periodically called from 
FrameManager. Il will check each server to sec if 
any one needs to be shutdown. 

Concurrency: Sequential 

Operation name: 

gclScrvxr 

Public member of: ServerManager 
Return Class: Server* 
Arguments: 

char* aServer 
Documentation: 

Return a server of the specified type. Il 
first check the ser\'er list to see if any one of 
that type is idle. If it is, it return the reference 
to that one and update the status. If not, il will 
call the addSer^ cr function lo try to add one. 

Concurrency; Sequential 
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What is claimed is: 

1. A decision support system, comprising: 
decision support frames providing a plurality of views 

into a supply chain, said frames including decision 
logic; 

a model engine comprising modeling processes for ana- 
lyzing the supply chain, the modeling processes being 
assembled by the decision logic to address a decision 
related to one of the plurality of views; and 

a frame manager managing the execution of the modeling 
processes lo provide information for said frames. 

2. A system as recited in claim 1, further comprising a 
database management system supplying database infomia- 
lion to the modeling processes and said frame manager. 

3. A system as recited in claim 1, wherein said system 
comprises a server mode including said model engine and 
said frame manager and a client mode comprising said 
decision frames, 

4. A system as recited in claim 2, wherein a database of 
said database management system comprises an inventory 
data space, a supply data space and a demand data space. 

5. A system as recited in claim 2, wherein a database of 
said database management system includes a supply chain 
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network including a component supply node, a production 
node, an inventory node and a demand node. 

6. A system as recited in claim 1, wherein said modeling 
processes comprise a component procurement policy devel- 
opment module, a finished goods distribution network 
design module, an ag^egate production planning module, a 
finished goods inventory management module, a sales fore- 
casting and planning module, a market data analysis module 
and a vendor managed replenishment module. 

7. A system as recited in claim 1, wherein said manager 
comprises a system integrator and a functional integrator. 

8. A system as recited in claim 1, wherein the supply chain 
includes sales, inventory and production. 

9. A decision support system, comprising: 

a plurality of frames which provide viewing information 

for a supply chain; 
a model engine including at least one module capable of 

analyzing changes on the supply chain; and 
a frame manager coupled to the model engine capable of 

managing execution of the module and providing an 

output to at least one of the plurality of frames. 

4 * * * * 
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